View a markdown version of this page

피해야 할 태그 지정 방법 - AWS 권장 가이드

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

피해야 할 태그 지정 방법

AWS에서 객체 또는 인프라에 태그를 지정할 경우 구현해야 할 사례가 있지만 피해야 할 사례도 있습니다.

일관되지 않은 태그 지정

목표 섹션에 설명된 대로 태그 지정 없이는 높은 수준의 자동화, 정리 또는 모니터링을 수행할 수 없습니다. 마찬가지로 불완전하거나 일관되지 않은 태그로 인해 자동화 또는 모니터링에 필요한 정보가 완전하지 않아 신뢰할 수 없는 결과가 발생합니다.

태그 지정 전략을 사용하여 모든 프로젝트의 총 비용을 계산하는 시나리오를 가정합니다. 이 전략은 개념 증명(PoC) 단계에서 시작하여 프로덕션 단계로 끝납니다. 프로젝트 판매 예측 P1, D1, Pr1 예제와 프로젝트 사후 판매 유지 관리 P2, D2, Pr2 예제의 경우 데이터 및 리소스에 태그가 적용된 다음 시나리오를 고려합니다.

판매 예측

P1 예제: PoC 프로젝트(도메인 및 타임스탬프 누락).

env: "poc" project: "sales forecasting"

D1 예제: 개발 단계(도메인 누락).

env: "dev" project: "sales forecasting" timestamp: 20210505T12:34:55

Pr1 예제: 프로덕션 단계(모든 값 존재).

env: "prod" project: "sales forecasting" domain: "machine learning" timestamp: 20210505T12:34:55

판매 예측 프로젝트의 경우:

  • P1 예제에서는 객체의 도메인 또는 타임스탬프를 언급하지 않습니다.

  • D1 예제에서도 프로젝트의 도메인을 언급하지 않습니다.

  • Pr1 예제에는 필요한 모든 데이터가 있습니다.

P1 및 D1 예제에서는 도메인이 정의되지 않았기 때문에 계획에 대한 잘못된 보고 또는 추정이 발생합니다.

사후 영업 유지 관리

P2 예제: PoC 프로젝트(모든 태그 누락).

D2 예제: 개발 단계(프로젝트 누락).

env: "dev" domain: "machine learning" timestamp: 20210505T12:34:55

Pr2 예제: 프로덕션 단계(모든 값 존재).

env: "prod" project: "post sales maintenance" domain: "machine learning" timestamp: 20210505T12:34:55

프로젝트에서 사후 영업 유지 관리의 경우:

  • P2 예제에는 정보가 없으므로 추적할 수 없습니다.

  • D2 예제에서는 프로젝트 이름을 언급하지 않으므로 추적할 수 없습니다.

  • Pr2 예제에는 필요한 모든 데이터가 있습니다.

P2 및 D2 예제에서는 누락되거나 일관되지 않은 태그로 인해 보고가 잘못되거나 계획이 진행 중이거나 과소 보고가 발생합니다.

따라서 태그 지정 전략을 일관된 방식으로 구현하는 것이 중요합니다.

태그의 잘못된 데이터 및 민감한 데이터

태그 지정은 부정확하거나 민감한 정보 또는 프라이빗 정보와 함께 사용하는 경우 생산성을 저해할 수 있습니다. 잘못된 태그는 오해의 소지가 있는 결과를 초래할 수 있습니다. 개인 식별 정보(PII)와 같은 민감한 데이터가 포함된 태그를 사용하면 고객과 직원의 보안이 위험에 처할 수 있습니다.

태그의 잘못된 정보

태그 지정 전략을 사용하여 각 도메인 또는 부서의 총 비용을 계산하는 시나리오를 가정합니다. 방금 데이터 수집 단계를 완료했으며 기계 학습으로 진행 중입니다. 다음 예제에는 프로젝트의 이전 단계에서 복사된 사용자 지정 태그가 포함되어 있습니다.

env: "development" project: "sales prediction" domain: "data ingestion" timestamp: 20210505T12:34:55

도메인에 올바른 도메인(machine learning) 대신 이전 프로젝트 단계에서 레이블이 data ingestion으로 잘못 지정되었습니다. 이제 data ingestion 도메인에 대한 보고서에 더 높은 비용, 시간 범위 및 리소스 할당이 표시됩니다. machine learning 도메인은 이러한 보고서에 대해 더 낮은 값을 표시합니다. 이로 인해 계획, 예산 할당 및 기한 추정이 잘못 생성될 수 있습니다.

기능 시스템에는 올바른 태그를 보유하는 것이 중요합니다.

태그의 민감한 정보

AWS에서는 객체에서 PII를 식별하기 위한 여러 도구를 제공합니다. 이러한 도구에는 개인을 식별하는 데 사용할 수 있는 데이터를 찾기 위한 Amazon MacieAWS Glue 민감한 데이터 감지가 포함됩니다. 그러나 PII 또는 민감한 데이터를 태그에 사용하지 않는 것이 중요합니다.

PII가 수정되거나 익명화된 Amazon S3의 다음 파일 예제를 고려합니다.

{ firstName: "67A1790DCA55B8803AD024EE28F616A2", lastName: "DRG54654DFHJGDYYRD", age: 21, city : "Frankfurt", probability_of_purchase: 48.858093, veggieName: "broccoli", creditcard: false }

고객 이름과 성이 해시 처리된 것을 확인할 수 있습니다. 그러나 이 예제에서 레코드에는 다음과 같은 사용자 지정 태그가 있습니다.

owner: "Company XYZ" about: "John Doe" contact: "johnthegreat@email.com" timestamp: 20210505T12:34:55

이 경우 파일 자체에는 PII가 없지만 태그에는 민감한 정보가 포함되어 있습니다. 이 경우 파일 또는 객체를 공유하거나 전송할 때 메타데이터도 공유하거나 전송할 수 있으므로 정보 유출 가능성이 커집니다. 데이터베이스, 테이블, 작업 및 함수와 같은 다른 AWS 리소스에서도 마찬가지입니다.

따라서 태그에 프라이빗 정보를 사용하지 않는 것이 매우 중요합니다. 이 동일한 개념은 중요한 정보 또는 비공개 정보에도 확장 적용됩니다.