기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

# 태그란 무엇입니까?
<a name="what-are-tags"></a>

태그는 리소스에 대한 메타데이터를 보관하기 위해 리소스에 적용되는 [https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html)입니다. 각 태그는 키와 값(선택 사항)으로 구성됩니다. 현재 모든 서비스와 리소스 유형이 태그를 지원하는 것은 아닙니다([리소스 그룹 태그 지정 API를 지원하는 서비스](https://docs.aws.amazon.com/resourcegroupstagging/latest/APIReference/supported-services.html) 참조). 다른 서비스는 자체 API를 통해 태그를 지원할 수 있습니다. 태그는 암호화되지 않으므로 개인 식별 정보(PII)와 같은 민감한 데이터를 저장하는 데 사용해서는 안 됩니다.

사용자가 생성하여 AWS CLI, API 또는를 사용하여 AWS 리소스에 적용하는 태그를 *사용자 정의* 태그라고 AWS Management Console 합니다. , AWS CloudFormation Elastic Beanstalk, Auto Scaling과 같은 여러 AWS 서비스는 생성 및 관리하는 리소스에 태그를 자동으로 할당합니다. 이러한 키를 *AWS 생성된* 태그라고 하며 일반적으로 `aws` 접두사가 붙습니다. 사용자 정의 태그 키에는 이 접두사를 사용할 수 없습니다.

 AWS 리소스에 추가할 수 있는 사용자 정의 태그 수에는 사용 요구 사항과 제한이 있습니다. 자세한 내용은 *AWS 일반 참조 가이드*의 [https://docs.aws.amazon.com/tag-editor/latest/userguide/best-practices-and-strats.html#tag-conventions](https://docs.aws.amazon.com/tag-editor/latest/userguide/best-practices-and-strats.html#tag-conventions) 참조하세요. AWS 생성된 태그는 이러한 사용자 정의 태그 제한에 포함되지 않습니다.

*표 1 - 사용자 정의 태그 키 및 값의 예*


|  인스턴스 ID  |  태그 키  |  태그 값  | 
| --- | --- | --- | 
| i-01234567abcdef89a  | CostCenter  | 98765  | 
|   | Stack  | Test  | 
| i-12345678abcdef90b  | CostCenter  | 98765  | 
|   | Stack  | Production  | 

*표 2 - AWS 생성된 태그의 예 *


|  AWS 생성된 태그 키  |  이론적 근거  | 
| --- | --- | 
| aws:ec2spot:fleet-request-id | 인스턴스를 시작한 Amazon EC2 스팟 인스턴스 요청을 식별합니다. | 
| aws:cloudformation:stack-name | 리소스를 생성한 AWS CloudFormation 스택을 식별합니다. | 
| lambda-console:blueprint |  AWS Lambda 함수의 템플릿으로 사용되는 블루프린트 식별  | 
| elasticbeanstalk:environment-name  | 리소스를 생성한 애플리케이션을 식별합니다. | 
| aws:servicecatalog:provisionedProductArn | 프로비저닝된 제품 Amazon 리소스 이름(ARN)  | 
| aws:servicecatalog:productArn | 프로비저닝된 제품이 시작된 제품의 ARN  | 

 AWS 생성된 태그는 네임스페이스를 형성합니다. 예를 들어 CloudFormation 템플릿에서에 함께 배포할 리소스 세트를 정의합니다. `stack`여기서 `stack-name`는 이를 식별하기 위해 할당하는 설명 이름입니다. `aws:cloudformation:stack-name`과 같은 키를 살펴보면 파라미터의 범위를 지정하는 데 사용되는 네임스페이스가 **aws**(*조직*), **cloudformation**(*서비스*), **stack-name**(*파라미터*) 등 세 가지 요소를 사용하는 것을 볼 수 있습니다.

 사용자 정의 태그는 네임스페이스를 사용할 수도 있으므로 조직 식별자를 접두사로 사용하는 것이 좋습니다. 이를 통해 태그가 관리형 스키마의 태그인지 환경에서 사용 중인 서비스 또는 도구에서 정의한 태그인지 빠르게 식별할 수 있습니다.

 [AWS에서 클라우드 기반 구축](https://docs.aws.amazon.com/whitepapers/latest/establishing-your-cloud-foundation-on-aws/choosing-tags.html) 백서에서는 구현해야 하는 태그 세트를 권장합니다. 비즈니스마다 허용 패턴이 다르고 특정 태그에 대한 목록도 다를 가능성이 높습니다. 표 3의 예를 살펴보면 다음과 같습니다.

*표 3 – 동일한 태그 키, 다른 값 검증 규칙*


|   Organization   |  태그 키  |  태그 값 검증  |  태그 값 예제  | 
| --- | --- | --- | --- | 
|  A 회사  | CostCenter  | 5432, 5422, 5499  | 5432  | 
|  B 회사  | CostCenter  | ABC\$1  | ABC123  | 

 이 두 스키마가 서로 다른 조직에 있는 경우에는 태그 충돌 문제가 없습니다. 그러나 이 두 환경이 병합되면 네임스페이스가 충돌할 수 있고 유효성 검사가 더 복잡해질 수 있습니다. 이 시나리오는 가능성이 낮을 것 같지만 비즈니스가 인수 또는 병합되고 관리형 서비스 공급자, 게임 게시자 또는 벤처 캐피탈 비즈니스와 함께 작업하는 클라이언트와 같은 다른 시나리오가 있으며, 여러 조직의 계정이 공유 AWS 조직의 일부입니다. 표 4와 같이 비즈니스 이름을 접두사로 사용하여 고유한 네임스페이스를 정의하면 이러한 문제를 피할 수 있습니다.

*표 4 – 태그 키의 네임스페이스 사용*


|   Organization   |  태그 키  |  태그 값 검증  |  태그 값 예제  | 
| --- | --- | --- | --- | 
| A 회사 | company-a:CostCenter  | 5432, 5422, 5499  | 5432  | 
| B 회사 | company-b:CostCenter  | ABC\$1  | ABC123  | 

 정기적으로 기업을 인수하고 매각하는 크고 복잡한 조직에서는 이러한 상황이 더 자주 발생합니다. 신규 인수의 프로세스와 관행이 그룹 전반에 걸쳐 조화를 이루면 상황이 해결됩니다. 네임스페이스를 구분하면 이전 태그의 사용을 보고하고 관련 팀에 연락하여 새 스키마를 채택할 수 있기 때문에 도움이 됩니다. 네임스페이스를 사용하여 범위를 나타내거나 조직 소유자에 맞게 조정된 사용 사례 또는 책임 영역을 나타낼 수도 있습니다.

*표 5 – 태그 키 내 범위 또는 사용 사례 범위의 예*


|  사용 사례  |  태그 키  |  이론적 근거  |  허용된 값  | 
| --- | --- | --- | --- | 
| 데이터 분류  | example-inc:info-sec:data-classification | 정보 보안 정의 데이터 분류 세트  | sensitive, company-confidential, customer-identifiable  | 
| 운영  | example-inc:dev-ops:environment | 테스트 및 개발 환경 일정 구현  | development, staging, quality-assurance, production  | 
| 재해 복구  | example-inc:disaster-recovery:rpo | 리소스에 대한 Recovery Point Objective(RPO) 정의  | 6h, 24h  | 
| 비용 할당  | example-inc:cost-allocation:business-unit | 재무팀은 각 팀의 사용량과 지출에 대한 비용 보고가 필요합니다. | corporate, recruitment, support, engineering  | 

 태그는 간단하고 유연합니다. 태그의 키와 값은 모두 가변 길이 문자열이며 폭넓은 문자 집합을 지원할 수 있습니다. 길이 및 문자 집합에 대한 자세한 내용은 *AWS 일반 참조*에서 [AWS 리소스 태그 지정](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html)을 참조하세요. 태그는 대소문자를 구분합니다. 즉, `costCenter` 및 `costcenter`는 서로 다른 태그 키입니다. 국가마다 단어의 철자가 다를 수 있으며 이로 인해 키에 영향을 미칠 수 있습니다. 예를 들어 미국에서는 키를 `costcenter`로 정의할 수 있지만 영국에서는 `costcentre`를 더 선호할 수 있습니다. 이러한 키는 리소스 태그 지정 관점에서 보면 서로 다릅니다. 태그 지정 전략의 일환으로 철자, 대소문자, 문장 부호를 정의합니다. 리소스를 만들거나 관리하는 모든 사람을 위한 참고 자료로 이 정의를 사용합니다. 이 항목에 대해서는 다음에 이어지는 [태그 지정 전략 구축](building-your-tagging-strategy.md) 단원에서 자세히 설명합니다.

**참고**  
태그 키는 대소문자를 구분하지만, 대소문자만 다른 태그 키들의 적용을 방지하기 위해 IAM 리소스에 대한 추가 검증 기능이 IAM에 있습니다. 대소문자만 다른 키들은 사용하지 않는 것이 좋습니다. 자세한 내용은 [IAM 리소스에 대한 태그를 참조하세요](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_tags.html#id_tags_rules).