기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다. # 태그 지정 전략 구축 많은 운영 관행과 마찬가지로 태그 지정 전략을 구현하는 것은 *반복과 개선의 과정*입니다. 우선순위에 따라 작게 시작해서 필요에 따라 태그 지정 스키마를 확장합니다. ![\[태그 지정 전략 반복 및 개선 주기를 그래픽으로 나타낸 다이어그램\]](http://docs.aws.amazon.com/ko_kr/whitepapers/latest/tagging-best-practices/images/tagging-strategy-cycle.png) 이 프로세스 전반에 걸쳐 소유권은 책임과 진행의 핵심입니다. 태그는 다양한 용도로 사용될 수 있으므로 전체 태깅 전략을 조직 내 책임 영역으로 나눌 수 있습니다. 태그 지정을 사용하면 리소스의 특성에 따라 달라지는 활동에 프로그래밍 방식으로 접근할 수 있습니다. 태그 지정으로 혜택을 받을 수 있는 이해 관계자의 범위는 조직의 규모와 운영 관행에 따라 달라집니다. 대규모 조직은 태그 지정 전략을 구축하고 구현하는 데 관련된 팀의 책임을 명확하게 정의하면 도움이 될 수 있습니다. 일부 이해 관계자는 태그 지정의 요구 사항 파악(사용 사례 정의)을 담당하고, 다른 이해 관계자는 태그 지정 전략의 유지, 구현 및 개선을 담당할 수 있습니다. 소유권을 할당하면 전략의 개별 측면을 구현할 수 있는 좋은 위치에 있게 됩니다. 적절한 경우 이러한 소유권을 정책으로 공식화하고 책임 매트릭스(예: RACI: Responsible, Accountable, Consulted 및 Informed) 또는 공동 책임 모델에 문서화할 수 있습니다. 소규모 조직에서는 요구 사항 정의부터 구현 및 시행에 이르기까지 팀이 태그 지정 전략에서 다양한 역할을 수행할 수 있습니다. # 요구 사항 및 사용 사례 정의 기본적으로 메타데이터를 사용해야 하는 필요성이 있는 이해 관계자와 협력하여 전략 구축을 시작합니다. 이러한 팀은 보고, 자동화 및 데이터 분류와 같이 활동을 지원하기 위해 리소스에 태그를 지정해야 하는 메타데이터를 정의합니다. 리소스를 구성하는 방법과 리소스를 매핑해야 하는 정책을 간략하게 설명합니다. 이러한 이해 관계자가 조직에서 가질 수 있는 역할과 기능의 예는 다음과 같습니다. + **재무**와 **LOB(Line of Business)**는 투자 가치를 비용과 연계하여 이해함으로써 불평등을 해결할 때 취해야 할 조치의 우선순위를 정해야 합니다. *창출된 비용 대비 가치*를 이해하면 실패한 LOB(Line of Business) 또는 제품 서비스를 식별하는 데 도움이 됩니다. 이는 지속적인 지원, 대안 채택(예: SaaS 서비스 또는 관리 서비스 사용) 또는 수익성이 낮은 비즈니스 서비스의 사용 중지에 대한 정보에 입각한 결정으로 이어집니다. + **거버넌스** 및 **규정 준수**는 권한, 정책 및 모니터링과 같은 적절한 제어 및 감독을 적용하기 위해 데이터의 분류(예: 공개, 민감 또는 기밀), 특정 워크로드가 특정 표준 또는 규정에 대한 감사 범위에 속하는지 여부, 서비스의 중요도(서비스 또는 애플리케이션이 비즈니스에 중요한지 여부)를 이해해야 합니다. + **운영** 및 **개발 부서**는 워크로드 수명 주기, 지원 제품의 구현 단계, 릴리스 단계 관리(예: 개발, 테스트, 프로덕션 분할), 관련 지원 우선순위 및 이해 관계자 관리 요구 사항을 이해해야 합니다. 백업, 패치, 관찰성, 사용 중단과 같은 업무도 정의하고 이해해야 합니다. + **정보 보안(InfoSec)** 및 **보안 운영(SecOps)**은 적용해야 하는 제어와 권장되는 제어를 설명합니다. 일반적으로 InfoSec은 제어의 구현을 정의하며 SecOps는 일반적으로 이러한 제어의 관리를 담당합니다. 사용 사례, 우선순위, 조직 규모, 운영 관행에 따라 재무(조달 포함), 정보 보안, 클라우드 지원, 클라우드 운영 등 조직 내 다양한 팀을 대표해야 할 수도 있습니다. 또한 패치, 백업 및 복원, 모니터링, 작업 예약, 재해 복구와 같은 기능에 대한 애플리케이션 및 프로세스 소유자의 대리인도 필요합니다. 이들 담당자는 태그 지정 전략의 정의, 구현 및 효율성 측정을 주도하는 데 도움을 줍니다. 담당자는 이해관계자와 사용 사례를 [거꾸로 검토하여](https://www.youtube.com/watch?v=aFdpBqmDpzM) 부서 간 워크숍을 진행해야 합니다.** 워크숍에서는 각자의 관점과 요구 사항을 공유하고 전반적인 전략을 수립하는 데 도움을 줄 기회를 얻습니다. 참가자의 예와 다양한 사용 사례에 대한 참여는 이 백서 뒷부분에 설명되어 있습니다. 또한 이해 관계자는 필수 태그의 키를 정의 및 검증하고 선택적 태그의 범위를 추천할 수 있습니다. 예를 들어 재무팀은 리소스를 내부 비용 센터, 사업부 또는 둘 다에 연결해야 할 수 있습니다. 따라서 특정 태그 키(예: `CostCenter` 및 `BusinessUnit`)를 필수로 설정해야 할 수도 있습니다. 개별 개발 팀은 자동화를 위해 `EnvironmentName`, `OptIn` 또는 `OptOut`과 같은 추가 태그를 사용하기로 결정할 수 있습니다. 주요 이해 관계자는 태그 지정 전략 접근 방식에 동의하고 다음과 같은 규정 준수 및 거버넌스 관련 질문에 대한 답변을 문서화해야 합니다. + 해결해야 할 사용 사례는 무엇입니까? + 리소스 태그 지정(구현)은 누가 담당하나요? + 태그는 어떻게 적용되며 어떤 방법과 자동화가 사용되나요(사전 또는 사후)? + 태그 지정의 효율성과 목표는 어떻게 측정되나요? + 태그 지정 전략을 얼마나 자주 검토해야 하나요? + 개선을 주도하는 사람은 누구인가요? 어떻게 이루어지나요? 그러면 Cloud Enablement, Cloud Business Office, Cloud Platform Engineering과 같은 비즈니스 부서가 진행 상황을 측정하고, 장애물을 제거하고, 중복되는 노력을 줄임으로써 태그 지정 전략을 구축하는 프로세스를 촉진하고, 채택을 촉진하고, 애플리케이션의 일관성을 보장하는 역할을 할 수 있습니다. # 태그 지정 스키마 정의 및 게시 필수 태그와 선택적 태그 AWS 모두에 리소스에 태그를 지정할 때 일관된 접근 방식을 사용합니다. 포괄적인 태그 지정 스키마를 사용하면 이러한 일관성을 유지할 수 있습니다. 다음 예제는 시작하는 데 도움이 될 수 있습니다. + 필수 태그 키에 대한 동의 + 허용 가능한 값 및 태그 이름 지정 규칙(대/소문자, 대시 또는 밑줄, 계층 구조 등) 정의 + 확인 값은 개인 식별 정보(PII)를 구성하지 않음 + 누가 새 태그 키를 정의하고 생성할 수 있는지 결정 + 새 필수 태그 값을 추가하는 방법과 선택적 태그를 관리하는 방법에 대한 동의 다음 [태그 지정 범주](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html) 표를 검토합니다. 이 표는 태그 지정 스키마에 포함할 수 있는 항목의 기준으로 사용할 수 있습니다. 여전히 태그 키에 사용할 규칙과 각각에 허용되는 값을 결정해야 합니다. 태그 지정 스키마는 환경에 맞게 이를 정의하는 문서입니다. 표 6 - 최종 태그 지정 스키마의 예** | 사용 사례 | 태그 키 | 이론적 근거 | 허용된 값(나열된 또는 값 접두사/접미사) | 비용 할당에 사용됨 | 리소스 유형 | Scope | 필수 | | --- | --- | --- | --- | --- | --- | --- | --- | | 비용 할당 | example-inc:cost-allocation:ApplicationId | 각 사업부에서 창출된 비용 대비 가치 추적 | DataLakeX, RetailSiteX | Y | 모두 | 모두 | 필수 | | 비용 할당 | example-inc:cost-allocation:BusinessUnitId | 사업부별 비용 모니터링 | Architecture, DevOps, Finance | Y | 모두 | 모두 | 필수 | | 비용 할당 | example-inc:cost-allocation:CostCenter | 비용 센터별 비용 모니터링 | 123-\$1 | Y | 모두 | 모두 | 필수 | | 비용 할당 | example-inc:cost-allocation:Owner | 이 워크로드를 책임지는 예산 보유자는 누구입니까? | Marketing, RetailSupport | Y | 모두 | 모두 | 필수 | | 액세스 통제 | example-inc:access-control:LayerId | 역할에 따라 리소스에 대한 액세스 권한을 부여할 하위 구성 요소/계층 식별 | DB\$1Layer, Web\$1Layer, App\$1Layer | N | 모두 | 모두 | 선택 사항 | | 자동화 | example-inc:automation:EnvironmentId | 소프트웨어 개발 라이프사이클(SDLC) 단계라고도 하는 테스트 및 개발 환경의 일정 수립 구현 | Prod, Dev, Test, Sandbox | N | EC2, RDS, EBS | 모두 | 필수 | | DevOps | example-inc:operations:Owner | 리소스 생성 및 유지 관리를 담당하는 팀/스쿼드는 어디입니까? | Squad01 | N | 모두 | 모두 | 필수 | | 재해 복구 | example-inc:disaster-recovery:rpo | 리소스에 대한 Recovery Point Objective(RPO) 정의 | 6h, 24h | N | S3, EBS | Prod | 필수 | | 데이터 분류 | example-inc:data:classification | 규정 준수 및 거버넌스를 위한 데이터 분류 | Public, Private, Confidential, Restricted | N | S3, EBS | 모두 | 필수 | | 규정 준수 | example-inc:compliance:framework | 워크로드에 적용되는 규정 준수 프레임워크 식별 | PCI-DSS, HIPAA | N | 모두 | Prod | 필수 | 태그 지정 스키마를 정의한 후에는 모든 관련 이해 관계자가 쉽게 참조하고 추적 가능한 업데이트를 위해 액세스할 수 있는 버전 제어 리포지토리에서 스키마를 관리합니다. 이 접근 방식을 사용하면 효율성이 향상되고 민첩성을 허용합니다. # AWS Organizations - 태그 정책 의 정책을 AWS Organizations 사용하면 조직의에 추가 유형의 거버넌스를 AWS 계정 적용할 수 있습니다. [https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_tag-policies.html](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_tag-policies.html) 플랫폼이 AWS 환경 내에서 스키마를 보고하고 선택적으로 적용할 수 있도록 태그 지정 스키마를 JSON 형식으로 표현하는 방법입니다. 태그 정책은 특정 리소스 유형의 태그 키에 허용되는 값을 정의합니다. 이 정책은 값 목록 형식이거나 접두사 뒤에 와일드카드 문자(`*`)를 붙이는 형식일 수 있습니다. 단순 접두사 접근 방식은 개별 값 목록보다 덜 엄격하지만 유지 관리가 덜 필요합니다. 다음 예제는 태그 지정 정책을 정의하여 지정된 키에 적합한 값을 검증하는 방법을 보여 줍니다. 사람에게 친숙한 표 형식의 스키마 정의를 사용하여 이 정보를 하나 이상의 태그 정책에 기록할 수 있습니다. 소유권 위임을 지원하기 위해 별도의 정책을 사용하거나 특정 시나리오에서만 일부 정책을 적용할 수 있습니다. ## ExampleInc-CostAllocation.json 다음은 비용 할당 태그를 보고하는 태그 정책의 예입니다. ``` { "tags": { "example-inc:cost-allocation:ApplicationId": { "tag_key": { "@@assign": "example-inc:cost-allocation:ApplicationId" }, "tag_value": { "@@assign": [ "DataLakeX", "RetailSiteX" ] } }, "example-inc:cost-allocation:BusinessUnitId": { "tag_key": { "@@assign": "example-inc:cost-allocation:BusinessUnitId" }, "tag_value": { "@@assign": [ "Architecture", "DevOps", "FinanceDataLakeX" ] } }, "example-inc:cost-allocation:CostCenter": { "tag_key": { "@@assign": "example-inc:cost-allocation:CostCenter" }, "tag_value": { "@@assign": [ "123-*" ] } } } } ``` ## ExampleInc-DisasterRecovery.json 다음은 재해 복구 태그를 보고하는 태그 정책의 예입니다. ``` { "tags": { "example-inc:disaster-recovery:rpo": { "tag_key": { "@@assign": "example-inc:disaster-recovery:rpo" }, "tag_value": { "@@assign": [ "6h", "24h" ] } } } } ``` 이 예에서는 `ExampleInc-CostAllocation` 태그 정책이 `Workloads` OU에 연결되므로 `Prod` 및 `Test` 하위 OU의 모든 계정에 적용됩니다. 마찬가지로 `ExampleInc-DisasterRecovery` 태그 정책은 `Prod` OU에 연결되므로 이 OU 아래의 계정에만 적용됩니다. [다중 계정을 사용한 환경 구성](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/organizing-your-aws-environment.html) 백서에서는 권장 OU 구조를 보다 자세히 살펴봅니다. ![\[OU 구조에 대한 태그 정책 첨부 및 효과적인 정책을 보여 주는 다이어그램\]](http://docs.aws.amazon.com/ko_kr/whitepapers/latest/tagging-best-practices/images/adding-tagging-to-policies-in-ou-structure.png) 다이어그램에서 `marketing-prod` 계정을 보면 두 태그 정책이 모두 이 계정에 적용되므로 *효과적인 정책*이라는 개념을 갖게 됩니다. 즉, 계정에 적용되는 특정 유형의 정책 컨볼루션입니다. 주로 리소스를 수동으로 관리하는 경우 콘솔의 [Resource Groups & Tag Editor:Tag 정책](https://console.aws.amazon.com/resource-groups/tag-policies)을 방문하여 효과적인 정책을 검토할 수 있습니다. 코드형 인프라(IaC) 또는 스크립팅을 사용하여 리소스를 관리하는 경우 [https://docs.aws.amazon.com/organizations/latest/APIReference/API_DescribeEffectivePolicy.html](https://docs.aws.amazon.com/organizations/latest/APIReference/API_DescribeEffectivePolicy.html) API 호출을 사용할 수 있습니다. # 태그 지정 구현 및 적용 이 섹션에서는 수동, 코드형 인프라(IaC), 지속적 통합/지속적 전달(CI/CD)과 같은 리소스 관리 전략에 사용할 수 있는 도구를 소개합니다. 이러한 접근 방식의 주요 차원은 배포 빈도가 점점 더 높아진다는 것입니다. ## 수동으로 관리되는 리소스 이는 일반적으로 [채택의 기초 또는 마이그레이션 단계](https://docs.aws.amazon.com/prescriptive-guidance/latest/migration-program-implementation/reviewing-frameworks.html)에 속하는 워크로드입니다. 일반적으로 이러한 워크로드는 기존의 서면 절차를 사용하여 구축되었거나 온프레미스 환경에서와 같은 도구를 사용하여 *마이그레이션*된 단순한 정적 워크로드 AWS Application Migration Service 입니다. Migration Hub 및 Application Migration Service와 같은 마이그레이션 도구는 마이그레이션 프로세스의 일부로 태그를 적용할 수 있습니다. 그러나 원래 마이그레이션 중에 태그가 적용되지 않았거나 이후 태그 지정 스키마가 변경된 경우 [Tag Editor](https://docs.aws.amazon.com/ARG/latest/userguide/tag-editor.html)(의 기능 AWS Management Console)를 사용하면 다양한 검색 기준을 사용하여 리소스를 검색하고 태그를 대량으로 추가, 수정 또는 삭제할 수 있습니다. 검색 기준에는 특정 태그나 값이 있거나 없는 리소스가 포함될 수 있습니다. AWS 리소스 태그 지정 API를 사용하면 이러한 함수를 프로그래밍 방식으로 수행할 수 있습니다. 이러한 워크로드가 현대화됨에 따라 Auto Scaling 그룹과 같은 리소스 유형이 도입되었습니다. 이러한 리소스 유형을 사용하면 탄력성이 향상되고 복원력이 향상됩니다. Auto Scaling 그룹이 사용자를 대신하여 Amazon EC2 인스턴스를 관리하지만 수동으로 생성한 리소스로 일관되게 EC2 인스턴스에 태그를 지정해야 할 수도 있습니다. [https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-launch-templates.html](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-launch-templates.html)은 Auto Scaling에서 생성하는 인스턴스에 적용할 태그를 지정하는 방법을 제공합니다. 워크로드의 리소스를 수동으로 관리하는 경우 리소스 태그 지정을 자동화하는 것이 유용할 수 있습니다. 다양한 솔루션을 사용할 수 있습니다. 한 가지 접근 방식은를 사용하는 것입니다. AWS Config 규칙이 접근 방식은 Lambda 함수를 확인하고 `required_tags` 시작하여 이를 적용할 수 있습니다. AWS Config 규칙 이 백서의 뒷부분에서 자세히 설명합니다. ## 코드형 인프라(IaC) 관리 리소스 AWS CloudFormation 는 AWS 환경의 모든 인프라 리소스를 프로비저닝하기 위한 공통 언어를 제공합니다. CloudFormation 템플릿은 자동화된 방식으로 AWS 리소스를 생성하는 JSON 또는 YAML 파일입니다. CloudFormation 템플릿을 사용하여 AWS 리소스를 생성할 때 CloudFormation 리소스 태그 속성을 사용하여 생성 시 지원되는 리소스 유형에 태그를 적용할 수 있습니다. IaC로 태그와 리소스를 관리하면 일관성을 유지하는 데 도움이 됩니다. 에서 리소스를 생성하면 AWS CloudFormation서비스는 AWS CloudFormation 템플릿에서 생성한 리소스에 AWS 정의된 태그 세트를 자동으로 적용합니다. 예를 들면 다음과 같습니다. ``` aws:cloudformation:stack-name aws:cloudformation:stack-id aws:cloudformation:logical-id ``` AWS CloudFormation 스택을 기반으로 리소스 그룹을 쉽게 정의할 수 있습니다. 이러한 AWS 정의된 태그는 스택에서 생성된 리소스에 상속됩니다. 그러나 Auto Scaling 그룹 내의 Amazon EC2 인스턴스의 경우 AWS CloudFormation 템플릿의 Auto Scaling 그룹 정의에서 [`AWS::AutoScaling::AutoScalingGroup` TagProperty](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-as-tags.html)를 설정해야 합니다. 또는 Auto Scaling 그룹과 함께 [EC2 시작 템플릿](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-ec2-launchtemplate.html)을 사용하는 경우 해당 정의에 태그를 정의할 수 있습니다. Auto Scaling 그룹 또는 AWS 컨테이너 서비스와 함께 [EC2 시작 템플릿을](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-ec2-launchtemplate.html) 사용하는 것이 좋습니다. 이러한 서비스는 Amazon EC2 인스턴스의 일관된 태그 지정을 보장하고 [여러 인스턴스 유형 및 구매 옵션에 걸친 Auto Scaling](https://aws.amazon.com/blogs/aws/new-ec2-auto-scaling-groups-with-multiple-instance-types-purchase-options/)을 지원하여 복원력을 개선하고 컴퓨팅 비용을 최적화하는 데 도움이 됩니다. [AWS CloudFormation 후크는](https://aws.amazon.com/blogs/mt/proactively-keep-resources-secure-and-compliant-with-aws-cloudformation-hooks/) 개발자에게 애플리케이션의 주요 측면을 조직의 표준에 맞게 유지할 수 있는 수단을 제공합니다. *경고*를 제공하거나 *배포를 방지*하도록 후크를 구성할 수 있습니다. 이 기능은 Auto Scaling 그룹이 시작하는 모든 Amazon EC2 인스턴스에 고객 정의 태그를 적용하도록 구성되어 있는지 또는 모든 Amazon S3 버킷이 필요한 암호화 설정으로 생성되었는지 확인하는 등 템플릿의 주요 구성 요소를 확인하는 데 가장 적합합니다. 두 경우 모두이 규정 준수에 대한 평가는 배포 전 AWS CloudFormation 후크를 사용하여 배포 프로세스의 앞부분에 푸시됩니다. AWS CloudFormation 는 템플릿에서 프로비저닝된 리소스([드리프트 감지를 지원하는 리소스 참조](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/resource-import-supported-resources.html))가 수정되었고 리소스가 더 이상 예상 템플릿 구성과 일치하지 않는 경우를 감지하는 기능을 제공합니다. 이를 *드리프트*라고 합니다. 자동화를 사용하여 IaC를 통해 관리되는 리소스에 태그를 적용하면 태그가 수정되어 드리프트가 발생합니다. IaC를 사용하는 경우 현재 IaC 템플릿의 일부로 태그 지정 요구 사항을 관리하고, AWS CloudFormation 후크를 구현하고, 자동화에서 사용할 수 있는 AWS CloudFormation Guard 규칙 세트를 게시하는 것이 좋습니다. ## CI/CD 파이프라인 관리 리소스 워크로드의 성숙도가 높아짐에 따라 지속적 통합 및 연속 배포(CI/CD)와 같은 기술이 채택될 가능성이 높습니다. 이러한 기술을 사용하면 테스트 자동화가 향상되어 작은 변경 사항을 더 자주 배포하기 쉬워져 배포 위험을 줄일 수 있습니다. 배포로 인해 발생하는 예상치 못한 동작을 감지하는 관찰성 전략을 사용하면 사용자에게 미치는 영향을 최소화하면서 배포를 자동으로 롤백할 수 있습니다. 하루에 수십 번 배포하는 단계에 이르면 태그를 소급하여 적용하는 것은 더 이상 실용적이지 않습니다. 모든 것을 코드나 구성으로 표현하고 버전을 제어하고 가능한 경우 프로덕션 환경에 배포하기 전에 테스트 및 평가를 거쳐야 합니다. 통합 [개발 및 운영(DevOps) 모델](https://aws.amazon.com/devops/what-is-devops/)에서는 많은 사례가 운영 고려 사항을 코드로 다루고 배포 수명 주기 초기에 이를 검증합니다. AWS CloudFormation 템플릿이 개발자의 시스템을 떠나기 전에 정책을 충족하는지 확신할 수 있도록 프로세스 초기에 이러한 검사를 최대한 빨리 푸시하는 것이 좋습니다( AWS CloudFormation 후크와 함께 표시됨). [AWS CloudFormation Guard 2.0](https://aws.amazon.com/blogs/mt/introducing-aws-cloudformation-guard-2-0/)은 CloudFormation으로 정의할 수 있는 모든 항목에 대한 예방 규정 준수 규칙을 작성할 수 있는 수단을 제공합니다. 템플릿은 개발 환경의 규칙에 따라 검증되었습니다. 분명히 이 기능은 다양한 용도로 사용되지만 이 백서에서는 [`AWS::AutoScaling::AutoScalingGroup` TagProperty](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-as-tags.html)를 항상 사용할 수 있는 몇 가지 예제를 살펴보겠습니다. 다음은 CloudFormation Guard 규칙에 예입니다. ``` let all_asgs = Resources.*[ Type == 'AWS::AutoScaling::AutoScalingGroup' ] rule tags_asg_automation_EnvironmentId when %all_asgs !empty { let required_tags = %all_asgs.Properties.Tags.*[ Key == 'example-inc:automation:EnvironmentId' ] %required_tags[*] { PropagateAtLaunch == 'true' Value IN ['Prod', 'Dev', 'Test', 'Sandbox'] <> } } rule tags_asg_costAllocation_CostCenter when %all_asgs !empty { let required_tags = %all_asgs.Properties.Tags.*[ Key == 'example-inc:cost-allocation:CostCenter' ] %required_tags[*] { PropagateAtLaunch == 'true' Value == /^123-/ <> } } ``` 코드 예제에서는 `AutoScalingGroup` 유형의 모든 리소스에 대해 템플릿을 필터링한 다음 두 가지 규칙을 적용합니다. + **`tags_asg_automation_EnvironmentId`** - 이 키를 가진 태그가 존재하고 허용된 값 목록 내에 값이 있고 `PropagateAtLaunch`가 `true`로 설정되어 있는지 확인합니다. + **`tags_asg_costAllocation_CostCenter`** - 이 키를 가진 태그가 존재하고 정의된 접두사 값으로 시작하는 값이 있고 `PropagateAtLaunch`가 `true`로 설정되어 있는지 확인합니다. ## 적용 앞서 설명한 것처럼 **Resource Groups & Tag Editor**는 조직의 OU에 적용되는 태그 정책에 정의된 태그 지정 요구 사항을 리소스가 충족하지 못하는 부분을 식별할 수 있는 수단을 제공합니다. 조직 구성원 계정 내에서 **Resource Groups & Tag Editor** 콘솔 도구에 액세스하면 해당 계정과 태그 정책의 요구 사항을 충족하지 못하는 계정 내 리소스에 적용되는 정책을 확인할 수 있습니다. 관리 계정에서 액세스하는 경우(태**그 정책에** 아래 서비스에서 *액세스가 활성화된* 경우 AWS Organizations) [조직의 연결된 모든 계정에 대한 태그 정책 규정 준수를 볼 수 있습니다](https://docs.aws.amazon.com/ARG/latest/userguide/tag-policies-orgs-evaluating-org-wide-compliance.html). 태그 정책 자체 내에서 특정 리소스 유형에 대한 적용을 활성화할 수 있습니다. 다음 정책 예시에서는 `ec2:instance` 유형의 모든 리소스 및 `ec2:volume`이 정책을 준수하도록 요구하는 강제 적용을 추가했습니다. 태그 정책으로 리소스를 평가하려면 리소스에 태그가 있어야 하는 등의 몇 가지 알려진 제한 사항이 있습니다. 목록은 [태그 정책 시행을 지원하는 리소스](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_supported-resources-enforcement.html)를 참조하세요. ### ExampleInc-Cost-Allocation.json 다음은 비용 할당 태그를 보고 및/또는 적용하는 태그 정책의 예입니다. ``` { "tags": { "example-inc:cost-allocation:ApplicationId": { "tag_key": { "@@assign": "example-inc:cost-allocation:ApplicationId" }, "tag_value": { "@@assign": [ "DataLakeX", "RetailSiteX" ] }, "enforced_for": { "@@assign": [ "ec2:instance", "ec2:volume" ] } }, "example-inc:cost-allocation:BusinessUnitId": { "tag_key": { "@@assign": "example-inc:cost-allocation:BusinessUnitId" }, "tag_value": { "@@assign": [ "Architecture", "DevOps", "FinanceDataLakeX" ] }, "enforced_for": { "@@assign": [ "ec2:instance", "ec2:volume" ] } }, "example-inc:cost-allocation:CostCenter": { "tag_key": { "@@assign": "example-inc:cost-allocation:CostCenter" }, "tag_value": { "@@assign": [ "123-*" ] }, "enforced_for": { "@@assign": [ "ec2:instance", "ec2:volume" ] } } } } ``` **AWS Config (`required_tag`)** AWS Config 는 AWS 리소스의 구성을 평가, 감사 및 평가할 수 있는 서비스입니다([에서 지원하는 리소스 유형 AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/resource-config-reference.html) 참조). 태그 지정의 경우 `required_tags` 규칙을 사용하여 특정 키의 태그가 없는 리소스를 식별하는 데 사용할 수 있습니다([required\$1tags에서 지원하는 리소스 유형](https://docs.aws.amazon.com/config/latest/developerguide/required-tags.html) 참조). 이전 예제에서 모든 Amazon EC2 인스턴스에 키가 있는지 테스트할 수 있습니다. 키가 존재하지 않는 경우 인스턴스는 규정 미준수로 등록됩니다. 이 AWS CloudFormation 템플릿은 테이블, Amazon S3 버킷, Amazon EC2 인스턴스 및 Amazon EBS 볼륨에서 설명하는 필수 키가 있는지 테스트하는 AWS Config 규칙에 대해 설명합니다. ``` Resources: MandatoryTags: Type: AWS::Config::ConfigRule Properties: ConfigRuleName: ExampleIncMandatoryTags Description: These tags should be in place InputParameters: tag1Key: example-inc:cost-allocation:ApplicationId tag2Key: example-inc:cost-allocation:BusinessUnitId tag3Key: example-inc:cost-allocation:CostCenter tag4Key: example-inc:automation:EnvironmentId Scope: ComplianceResourceTypes: - "AWS::S3::Bucket" - "AWS::EC2::Instance" - "AWS::EC2::Volume" Source: Owner: AWS SourceIdentifier: REQUIRED_TAGS ``` 리소스를 수동으로 관리하는 환경의 경우 AWS Lambda 함수를 통한 자동 문제 해결을 사용하여 누락된 태그 키를 리소스에 자동으로 추가하도록 AWS Config 규칙을 개선할 수 있습니다. 정적 워크로드에는 잘 작동하지만 IaC 및 배포 파이프라인을 통해 리소스를 관리하기 시작하면 효율성이 점차 떨어집니다. **AWS Organizations - 서비스 제어 정책(SCPs)**은 조직의 권한을 관리하는 데 사용할 수 있는 조직 정책의 한 유형입니다. SCP는 조직 또는 조직 단위(OU)의 모든 계정에 사용 가능한 최대 권한을 중앙에서 제어합니다. SCP는 조직에 속한 계정이 관리하는 사용자 및 역할에만 영향을 줍니다. 리소스에 직접적인 영향을 미치지는 않지만 태그 지정 작업에 대한 권한을 포함하여 사용자 및 역할의 권한을 제한합니다. 태그 지정과 관련하여 SCP는 태그 정책이 제공할 수 있는 내용 외에도 태그 적용을 위한 추가 세분성을 제공할 수 있습니다. 다음 예제에서는 정책이 `example-inc:cost-allocation:CostCenter` 태그가 없는 `ec2:RunInstances` 요청은 거부합니다. 다음은 거부 SCP입니다. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "DenyRunInstanceWithNoCostCenterTag", "Effect": "Deny", "Action": "ec2:RunInstances", "Resource": [ "arn:aws:ec2:*:*:instance/*" ], "Condition": { "Null": { "aws:RequestTag/example-inc:cost-allocation:CostCenter": "true" } } } ] } ``` ------ 연결 계정에 적용되는 효과적인 서비스 제어 정책은 설계상 검색할 수 없습니다. SCP로 태그를 적용하는 경우 개발자가 리소스가 계정에 적용된 정책을 준수하는지 확인할 수 있도록 개발자가 문서를 사용할 수 있어야 합니다. 계정 내에서 CloudTrail 이벤트에 대한 읽기 전용 액세스 권한을 제공하면 개발자가 리소스가 규정을 준수하지 못할 때 디버깅 작업을 수행할 수 있습니다. # 태그 지정 효과 측정 및 개선 추진 태그 지정 전략을 구현한 후에는 대상 사용 사례와 비교하여 그 효과를 측정하는 것이 중요합니다. 효과 측정은 사용 사례에 따라 달라집니다. 예제: + **비용 속성** - [AWS Cost Explorer](https://aws.amazon.com/aws-cost-management/aws-cost-explorer/)또는 [AWS Cost & Usage Report](https://aws.amazon.com/aws-cost-management/aws-cost-and-usage-reporting/)와 같은 도구를 사용하여 지출을 기준으로 리소스의 태그 지정 범위를 측정할 수 있습니다. 예를 들어 특히 특정 태그 키를 모니터링하면 *태그가 지정되거나 태그가 지정되지 않은* 리소스에서 요금이 발생하는 비율을 추적할 수 있습니다. + **자동화** - 원하는 결과가 달성되었는지 감사해야 할 수도 있습니다. 예를 들어 비프로덕션 Amazon EC2 인스턴스가 업무 시간 외에 일시 중단되는지 여부, 인스턴스 시작 및 중지 시간을 감사할 수 있습니다. 관리 계정 내의 [Resource Groups & Tag Editor](https://docs.aws.amazon.com/ARG/latest/userguide/resource-groups.html)는 조직의 모든 연결 계정에 대한 태그 정책 규정 준수를 분석할 수 있는 추가 기능을 제공합니다. 태그 지정 효율성 측정 결과를 기반으로 사용 사례 정의, 태그 지정 스키마 구현 또는 적용과 같은 단계에서 개선이나 변경이 필요한지 식별합니다. 필요에 따라 변경하고 원하는 효과를 얻을 때까지 주기를 반복합니다. 비용 기여도가 포함된 예제에서는 개선률을 확인할 수 있습니다. 리소스의 실제 태그 지정을 수행해야 하는 것은 개발자와 운영자이므로 소유권을 갖도록 하는 것이 중요합니다. 이는 팀이 AWS 채택 과정에서 일반적으로 맡는 유일한 추가 책임은 아닙니다. 보안 및 애플리케이션 개발과 운영에 드는 비용에 대한 책임을 높이는 것도 중요합니다. 조직은 종종 새로운 관행을 채택하도록 동기를 부여하는 수단으로 목표와 대상을 사용하므로 여기에도 적용할 수 있습니다.