

As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

# Práticas recomendadas
<a name="best-practice-tagging"></a>

Ao usar tags, é importante entender a estrutura atual ou potencial da empresa e do caso de uso. Usando essas informações, você pode escolher as tags corretas. Por exemplo, se você estiver criando um data lake para o departamento de pré-vendas e sabe que há planos para expandir o data lake para incluir dados do departamento de pós-venda, o uso da tag `department` ajudará a identificar os custos e o desempenho de cada departamento separadamente. O planejamento, a alocação de custos e a otimização do código ou dos dados podem ser identificados com mais precisão. Sem a tag `department`, se os dados de pré-venda precisarem de 15 minutos para a modelagem de dados e os dados de pós-venda precisarem de 45 minutos, os desenvolvedores precisarão dedicar mais tempo à análise da causa raiz. Com a tag `department`, os desenvolvedores sabem exatamente onde procurar.

## Ontologia de marcação
<a name="ontology"></a>

Juntos, os negócios e a tecnologia desempenham um papel importante na identificação das tags certas a serem usadas. Do ponto de vista comercial, uma empresa e um projeto sempre seguirão uma determinada estrutura. Por exemplo, na *região* EMEA, no *departamento* de RH, pode haver um *projeto* sobre a previsão da necessidade de contratação. Nesse caso, incluir metadados da estrutura existente seria importante para relatórios, monitoramento, limpeza e distribuições. Ao mesmo tempo, o departamento técnico entende que o projeto precisará do seguinte: 
+ *Fases* da coleta de dados por meio de um pipeline de dados composto por ingestão, limpeza e processamento de dados
+ Uma equipe de ML** **para fazer modelagem de dados para predição
+ Um pipeline de DevOps para orquestração de código, distribuído por meio de um ambiente de desenvolvimento, teste e produção

Todas as palavras-chave em itálico são estruturas de grupos de negócios e técnicos que devem ser associadas aos componentes de uma aplicação. Este é um exemplo de uma ontologia típica de marcação. Usando o exemplo, a tabela a seguir mostra os pares de chave/valor correspondentes para as tags.


|  |  | 
| --- |--- |
| **Chave** | **Valores** | 
| `department` | `human resources` | 
| `region` | `EMEA` | 
| `project` | `hiring forecast` | 
| `phase` | `3` | 
| `process` | `data ingestion`, `data cleaning`, `processing`, `modeling`, ou `sales forecasting` | 
| `domain` | `machine learning` ou `data pipeline` | 
| `creation` | `cdk`, `x framework`, `ingest pipeline`, ou `manual - empty` | 
| `status` | `development`, `testing`, `production access`, `reporting`, ou `onboarding` | 

## Governança de tags
<a name="governance"></a>

A configuração de mecanismos de governança ajuda a tornar a marcação consistente e programável em todos os recursos da AWS:
+ A *governança reativa* é usada para encontrar recursos que não estão devidamente marcados. Você pode usar ferramentas como a [API do Resource Groups Tagging](https://docs.aws.amazon.com/resourcegroupstagging/latest/APIReference/overview.html), as [regras do AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config_use-managed-rules.html) e os scripts personalizados.
+ A *governança proativa* significa que os usuários não têm permissão para criar recursos não marcados. Você pode usar ferramentas como o [AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html), o [AWS Service Catalog](https://docs.aws.amazon.com/servicecatalog/latest/userguide/end-user-console.html) e [políticas de tags](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_tag-policies.html) no AWS Organizations, ou permissões em nível de recurso do IAM.