728x90
Tag를 잘 활용하면 Tag별로 Cost를 계산하거나, 리소스 생명주기 관리에 있어 실수를 방지할 수 있다. 그런데 막상 공식적인 가이드는 잘없는것 같다. 그 이유는 사용자마다 비즈니스의 관점이 다르기 때문이다. 따라서 아래 공통사항과 UseCases 가이드를 참고해서 적절한 규칙을 정하는 것이 필요해 보인다.
공통사항
- 개인 식별 정보(PII)나 기타 기밀 정보 또는 민감한 정보를 태그에 저장하지 마십시오.
- 대/소문자를 구분하는 표준화된 태그 형식을 사용하고 모든 리소스 유형에 일관되게 적용합니다.
- 리소스 액세스 제어, 비용 추적, 자동화 및 조직 관리와 같은 다양한 용도를 지원하는 태그 지침을 고려합니다.
- 리소스 태그를 관리하는 데 도움이 되는 자동화 도구를 사용합니다. AWS Resource Groups 및 Resource Groups Tagging API를 사용하면 태그를 프로그래밍 방식으로 제어하여 태그와 리소스를 더 쉽게 자동으로 관리, 검색 및 필터링할 수 있습니다.
- 태그를 너무 적게 사용하는 것보다는 너무 많이 사용하는 편이 낫습니다.
- 변화하는 비즈니스 요구 사항에 맞춰 태그를 변경하는 것은 쉽지만 향후 변경에 따른 결과를 고려해야 합니다. 예를 들어 액세스 제어 태그를 변경하는 경우 해당 태그를 참조하며 리소스에 대한 액세스를 제어하는 정책도 업데이트해야 합니다.
- 다음을 사용하여 태그 정책을 만들고 배포하여 조직에서 채택하기로 선택한 태그 표준을 자동으로 적용할 수 있습니다.AWS Organizations. 태그 정책을 사용하면 유효한 키 이름과 각 키에 유효한 값을 정의하는 태그 규칙을 지정할 수 있습니다. 모니터만 선택할 수 있으므로 기존 태그를 평가하고 정리할 수 있습니다. 태그가 선택한 표준을 준수하면 태그 정책에서 적용을 설정하여 비준수 태그가 생성되지 않도록 할 수 있습니다.
UseCases
종류 | 기술 구분 | 자동화용 구분 | 비즈니스 구분 | 보안 구분 |
태그 내용 | 이름 – 개별 리소스 식별 애플리케이션 ID – 특정 애플리케이션과 관련된 리소스 식별 애플리케이션 역할 – 특정 리소스(예: 웹 서버, 메시지 브로커, 데이터베이스)의 기능 설명 클러스터 – 공통 구성을 공유하고 애플리케이션에 대해 특정 기능을 수행하는 리소스 팜 식별 환경 – 개발, 테스트, 프로덕션 리소스 간 구별 버전 – 리소스 또는 애플리케이션의 버전 구별 |
날짜/시간 – 리소스를 시작, 중지, 삭제 또는 교체해야 하는 날짜 또는 시간 식별 옵트인/옵트아웃 – 인스턴스 시작, 중지 또는 크기 조정과 같은 자동화된 작업에 리소스를 포함할지 여부 지정 보안 —Amazon VPC 흐름 로그의 암호화 또는 활성화와 같은 요구 사항 결정, 추가 조사가 필요한 라우팅 테이블 또는 보안 그룹 식별 |
프로젝트 – 리소스가 지원하는 프로젝트 식별 소유자 – 리소스에 대한 책임을 지는 사용자 식별 비용 센터/비즈니스 단위 – 대개 비용 할당 및 추적을 위해 리소스와 연관된 비용 센터 또는 비즈니스 단위 식별 고객 – 특정 리소스 그룹이 제공되는 특정 고객 식별 |
기밀성 – 리소스가 지원하는 특정 데이터 기밀성 수준에 대한 식별자 규정 준수 – 특정 규정 준수 요구 사항을 준수해야 하는 워크로드에 대한 식별자 |
'IaaS > 퍼블릭클라우드' 카테고리의 다른 글
(AWS) SSM 에 대해서 (0) | 2022.03.18 |
---|---|
(AWS) EKS를 ekscli로 Private Subnet으로 구축하기 (0) | 2022.03.17 |
(AWS) AWS리소스에 ElasticSearch를 적용하는 UseCases (0) | 2022.03.17 |
(AWS) X-Ray에 대해서 (0) | 2022.03.17 |
(AWS) S3 버킷에 Event Trigger를 생성하기 (0) | 2022.03.16 |