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á.

# Casos de uso das estatísticas
<a name="tagging-use-cases"></a>

**Topics**
+ [Tags para alocação de custos e gerenciamento financeiro](tags-for-cost-allocation-and-financial-management.md)
+ [Tags para operações e suporte](tags-for-operations-and-support.md)
+ [Tags para segurança de dados, gerenciamento de riscos e controle de acesso](tags-for-data-security-risk-management-and-access-control.md)

# Tags para alocação de custos e gerenciamento financeiro
<a name="tags-for-cost-allocation-and-financial-management"></a>

 Um dos primeiros casos de uso de tags que as organizações costumam abordar é a visibilidade e o gerenciamento de custos e uso. Geralmente, existem alguns motivos para isso: 
+  **Normalmente, é um cenário bem compreendido e os requisitos são bem conhecidos.** Por exemplo, as equipes financeiras querem ver o custo total das workloads e da infraestrutura que abrangem vários serviços, recursos, contas ou equipes. Uma forma de obter essa visibilidade de custos é por meio da marcação consistente dos recursos. 
+  **As tags e seus valores estão claramente definidos.** Normalmente, mecanismos de alocação de custos já existem nos sistemas financeiros de uma organização, por exemplo, rastreamento por centro de custo, unidade de negócios, equipe ou função da organização. 
+  **Retorno do investimento rápido e demonstrável.** É possível acompanhar as tendências de otimização de custos ao longo do tempo quando os recursos são marcados de forma consistente, por exemplo, para recursos que foram devidamente dimensionados, escalados automaticamente ou programados. 

 Entender como você incorre em custos AWS permite que você tome decisões financeiras informadas. Saber onde você incorreu em custos no nível de recursos, workload, equipe ou organização melhora sua compreensão do valor entregue no nível aplicável quando comparado aos resultados comerciais alcançados. 

 As equipes de engenharia podem não ter experiência com o gerenciamento financeiro de seus recursos. Contratar uma pessoa com uma habilidade especializada em gestão AWS financeira que possa treinar equipes de engenharia e desenvolvimento nos fundamentos da gestão AWS financeira e criar um relacionamento entre finanças e engenharia para promover a cultura FinOps ajudará a alcançar resultados mensuráveis para a empresa e incentivará as equipes a construir pensando nos custos. O estabelecimento de boas práticas financeiras é abordado em profundidade pelo [Pilar Otimização de custos](https://docs.aws.amazon.com/wellarchitected/latest/cost-optimization-pillar/welcome.html) do Well-Architected Framework, mas abordaremos alguns dos princípios fundamentais neste whitepaper. 

# Tags de alocação de custos
<a name="cost-allocation-tags"></a>

 A alocação de custos se refere à atribuição ou distribuição dos custos incorridos aos usuários ou beneficiários desses custos após um processo definido. No contexto deste whitepaper, dividimos a alocação de custos em dois tipos: *showback* e *estorno*. 

 As ferramentas e os mecanismos de *showback* contribuem para o reconhecimento de custos. O *estorno* ajuda na recuperação de custos e promove o reconhecimento de custos. O *showback* refere-se à apresentação, ao cálculo e à geração de relatórios de cobranças incorridas por uma entidade específica, como unidade de negócios, aplicação, usuário ou centro de custos. Por exemplo: “a equipe de engenharia de infraestrutura foi responsável por \$1 X de gastos com a AWS no mês passado”. O *estorno* se refere à cobrança real dos custos incorridos a essas entidades por meio dos processos contábeis internos de uma organização, como sistemas financeiros ou vales diários. Por exemplo: “\$1 X foi deduzido do orçamento da equipe de engenharia de infraestrutura” AWS . Em ambos os casos, marcar recursos de forma adequada pode ajudar a alocar o custo para uma entidade, com a única diferença sendo se existe a expectativa de que alguém efetuará ou não um pagamento. 

 A governança financeira da sua organização pode exigir uma contabilidade transparente dos custos incorridos no nível da aplicação, da unidade de negócios, do centro de custos e da equipe. A execução de atribuição de custos possibilitada pelas [tags de alocação de custos](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/cost-alloc-tags.html) fornece os dados necessários para atribuir com precisão os custos incorridos por uma entidade a partir de recursos devidamente marcados. 
+  **Responsabilidade**: garanta que o custo seja alocado aos responsáveis pelo uso dos recursos. Um único ponto de serviço ou grupo pode ser responsável pelas análises e relatórios de gastos. 
+  **Transparência financeira**: mostre uma visualização clara das alocações de caixa à TI criando painéis eficazes e análises de custos significativas para a liderança. 
+  **Investimentos respaldados em TI**: acompanhe o ROI com base no projeto, aplicação ou linha de negócios e capacite as equipes a tomarem melhores decisões de negócios, por exemplo, alocando mais fundos a aplicações que geram receita. 

 Em resumo, as tags de alocação de custos podem ajudar a dizer a você: 
+  Quem é o dono dos gastos e é responsável por otimizá-los? 
+  Qual workload, aplicação ou produto está incorrendo nos gastos? Qual ambiente ou estágio? 
+  Quais áreas de gastos estão crescendo mais rápido? 
+  Quanto gasto pode ser deduzido de um AWS orçamento com base nas tendências passadas? 
+  Qual foi o impacto dos esforços de otimização de custos em workloads, aplicações ou produtos específicos? 

 A ativação de etiquetas de recursos para alocação de custos ajuda na definição de práticas de medição dentro da organização que podem ser usadas para fornecer a visibilidade do AWS uso que aumenta a transparência na responsabilidade pelos gastos. Também se concentra em criar um nível adequado de granularidade com relação à visibilidade de custos e uso e influenciar os comportamentos de consumo da nuvem por meio de relatórios de alocação de custos e rastreamento de KPI. 

# Criar uma estratégia de alocação de custos
<a name="building-a-cost-allocation-strategy"></a>

## Definir e implementar um modelo de alocação de custos
<a name="defining-and-implementing-a-cost-allocation-model"></a>

Crie uma estrutura de contas e custos para os recursos que estão sendo implantados AWS. Estabeleça a relação entre os custos dos AWS gastos, como esses custos foram incorridos e quem ou o que incorreu nesses custos. As estruturas de custo comuns são baseadas em AWS Organizations Contas da AWS,, ambientes e entidades dentro de suas organizações, como uma linha de negócios ou carga de trabalho. As estruturas de custos podem se basear em vários atributos para permitir o exame dos custos de maneiras distintas ou em diferentes níveis de detalhamento, como transferir os custos de workloads individuais para a linha de negócios a que atendem.

 Ao escolher uma estrutura de custos que se alinhe aos resultados desejados, avalie os mecanismos de alocação de custos quanto à *facilidade de implementação* versus a *precisão desejada*. Isso pode incluir considerações em relação à responsabilidade, disponibilidade de ferramentas e mudanças culturais. Três modelos populares de alocação de custos com os quais AWS os clientes geralmente partem são: 
+  **Baseado em contas** — Esse modelo exige o mínimo de esforço e fornece alta precisão para devoluções e cobranças, além de ser adequado para organizações que têm uma estrutura de contas definida (e é consistente com as recomendações do whitepaper [Organizando seu AWS ambiente usando](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/organizing-your-aws-environment.html) várias contas). Isso fornece uma visibilidade clara dos custos por conta. Para visibilidade e alocação de custos, você pode usar o [AWS Cost Explorer](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/ce-what-is.html), o [Relatório de Custos e Uso da [https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/budgets-managing-costs.html](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/budgets-managing-costs.html), bem como o AWS Budgets](https://docs.aws.amazon.com/cur/latest/userguide/what-is-cur.html) para monitoramento e rastreamento de custos. Essas ferramentas fornecem opções de filtragem e agrupamento por. Contas da AWS Do ponto de vista da alocação de custos, esse modelo não precisa depender da marcação precisa de recursos individuais. 
+  **Baseado em unidade de negócios ou em equipe**: custo alocável para equipes, unidades de negócios ou organizações dentro de uma empresa. Esse modelo exige um esforço moderado, fornece alta precisão para showbacks e estornos e é adequado para organizações que definiram um estrutura de conta (normalmente usando o AWS Organizations), com separação entre várias equipes, aplicações e tipos de workload. Isso fornece uma visibilidade clara dos custos entre equipes e aplicações e, como benefício adicional, reduz o risco de atingir as [cotas de serviço da AWS](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html) em uma única Conta da AWS. Por exemplo, cada equipe pode ter cinco contas (`prod`, `staging`, `test`, `dev`, `sandbox`) e duas equipes e aplicações não compartilharão a mesma conta. Com essa estrutura, o [Categorias de Custos da AWS](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/manage-cost-categories.html) fornecerá a funcionalidade de agrupar contas ou outras tags (“metamarcação”) em categorias, que podem ser rastreadas nas ferramentas mencionadas no exemplo anterior. É importante observar que AWS Organizations permite a marcação de contas e unidades organizacionais (OUs), no entanto, essas tags não serão aplicáveis à alocação de custos e relatórios de faturamento (ou seja, você não pode agrupar ou filtrar seus custos AWS Cost Explorer por OU). AWS Cost Categories devem ser usadas para essa finalidade. 
+  **Baseado em tags**: esse modelo exige mais esforço em comparação com os dois anteriores e fornecerá alta precisão para showbacks e estornos, dependendo dos requisitos e da meta final. Embora seja altamente recomendável que você adote as práticas descritas no whitepaper [Organizando seu AWS ambiente usando várias contas](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/organizing-your-aws-environment.html), realisticamente, os clientes geralmente se deparam com estruturas de contas mistas e complexas que demoram para serem migradas. A implementação de uma estratégia de marcação rigorosa e eficaz é a chave nesse cenário, seguida pela [ativação de tags relevantes para alocação de custos](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/activating-tags.html) no console do Billing and Cost Management (em, as tags podem ser ativadas para alocação de custos somente AWS Organizations na conta do Management Payer). Depois que as tags são ativadas para alocação de custos, as ferramentas de visibilidade e alocação de custos mencionadas nos métodos anteriores podem ser usadas para showbacks e estornos. Observe que as tags de alocação de custos não são retrospectivas e só aparecerão nos relatórios de faturamento e nas ferramentas de controle de custos depois de serem ativadas para alocação de custos. 

 Resumindo, se você precisar controlar os custos por unidade de negócios, você pode usar [AWS Cost Categories](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/manage-cost-categories.html) para agrupar contas vinculadas dentro AWS da Organização adequadamente e visualizar esse agrupamento nos relatórios de faturamento. Ao criar contas separadas para ambientes de produção e de não produção, você também pode filtrar os custos relacionados aos ambientes em ferramentas como [AWS Cost Explorer](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/ce-what-is.html), por exemplo, ou monitorar esses custos usando o [AWS Budgets](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/budgets-managing-costs.html). Por fim, se seu caso de uso exigir um controle de custos mais detalhados, por exemplo, por workloads ou aplicações individuais, você poderá marcar recursos nessas contas adequadamente, [ativar essas chaves de tag para alocação de custos](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/activating-tags.html) na conta de gerenciamento e filtrar esse custo por chaves de tag nas ferramentas de relatórios de faturamento. 

## Analisar e aprimorar
<a name="establing-cost-reporting-and-monitoring-processes"></a>

 Comece identificando os tipos de custos que são importantes para as partes interessadas internas (por exemplo, gasto diário, custo por conta, custo por X, custos amortizados). Ao fazer isso, você pode mitigar os riscos orçamentários associados a gastos inesperados ou anômalos mais rapidamente do que esperar pela fatura finalizada. AWS As tags fornecem a atribuição que permite esses cenários de geração de relatórios. Os insights obtidos com os relatórios podem informar suas ações para mitigar o impacto de gastos anômalos e inesperados nos orçamentos financeiros. Quando há um aumento inesperado nos custos, é importante avaliar se houve um aumento inesperado no valor entregue para que você possa determinar se e qual ação é necessária. 

 Ao especificar uma interface de rede, tenha em mente as considerações e limitações a seguir: 
+  **AWS Organizations**: a alocação de custos em várias contas pode ser realizada por conta, grupos de contas ou grupo de tags criadas para recursos nessas contas. As tags criadas para recursos residentes em contas individuais em AWS Organizations podem ser usadas para alocação de custos somente na conta de gerenciamento. 
+  **AWS Conta** - A alocação de custos dentro de uma Conta da AWS pode ser realizada por dimensões adicionais, como serviços ou regiões. É possível marcar ainda mais recursos em uma conta e trabalhar com os grupos dessas tags de recursos. 
+  **Tags de alocação de custos**: tanto as tags criadas pelo usuário quanto as geradas pela AWS podem ser ativadas para alocação de custos, se necessário. Ativar tags para alocação de custos no console de faturamento (da conta de gerenciamento em AWS Organizations) ajuda com reembolsos e estornos. 
+  **Categorias** de AWS custo - As categorias de custos permitem agrupar contas e agrupar tags (“meta-tagging”) dentro de uma AWS organização, o que fornece ainda mais a capacidade de analisar os custos relacionados a essas categorias por meio de ferramentas como AWS Cost Explorer AWS Orçamentos e Relatório de Custos e Uso. AWS 

## Realizar showback e estorno para unidades de negócios, equipes ou organizações dentro da empresa
<a name="performing-showback-and-chargeback-for-business-units"></a>

 Atribua custos usando seu processo de alocação de custos apoiado por sua estrutura de custos e tags de alocação de custos. As tags podem ser usadas para oferecer showback às equipes que não são diretamente responsáveis pelo pagamento dos custos, mas são responsáveis por terem incorrido nesses custos. Essa abordagem fornece consciência de sua contribuição para os gastos e como esses custos são incorridos. Realize o estorno às equipes diretamente responsáveis pelos custos para recuperar as despesas dos recursos que consumiram e para informá-las sobre esses custos e sobre como foram incorridos. 

## Eficiência ou valor de medição e circulação KPIs
<a name="measuring-and-circulating-kpis"></a>

 Concorde com um conjunto de métricas de custo unitário ou KPI para medir o impacto de seus investimentos em gerenciamento financeiro na nuvem. Este exercício cria uma linguagem comum entre as partes interessadas em tecnologia e negócios e conta uma história baseada na eficiência, em vez de uma história focada exclusivamente em gastos absolutos e agregados. Para obter informações adicionais, consulte este blog que fala sobre [como as métricas unitárias podem ajudar a criar alinhamento entre as funções de negócios](https://aws.amazon.com/blogs/aws-cloud-financial-management/unit-metrics-help-create-alignment-between-business-functions/). 

## Alocar gastos não alocáveis
<a name="allocating-unallocatable-spend"></a>

 Dependendo das práticas contábeis da organização, diferentes tipos de cobrança podem exigir tratamento diferente. Identifique os recursos ou categorias de custo que não podem ser marcados. Dependendo dos serviços usados e daqueles planejados para serem usados, concorde com os mecanismos de como tratar e medir esses gastos não alocáveis. Por exemplo, verifique a lista de recursos que são compatíveis com o [AWS Resource Groups e o Tag Editor](https://docs.aws.amazon.com/ARG/latest/userguide/supported-resources.html) no *Guia do usuário do AWS Resource Groups e das tags*. 

 Um exemplo comum de categoria de custo que não pode ser marcada são algumas taxas para descontos baseados em compromissos, como instâncias reservadas (IR) e Savings Plans (SP). Embora as taxas de assinatura e as taxas de SP e IR não utilizadas não possam ser marcadas antes de aparecerem nas ferramentas de relatórios de faturamento, é possível rastrear como os descontos de IR e SP se aplicam a contas, recursos e suas tags no AWS Organizations após o fato. Por exemplo, é AWS Cost Explorer possível analisar o custo amortizado, agrupar esses gastos pelas chaves de tag relevantes e aplicar filtros relevantes ao seu caso de uso. No Relatório de Custos e Uso (CUR) da AWS , você pode filtrar as linhas que correspondem ao uso coberto pelos descontos de IR e SP (leia mais na seção de casos de uso da [documentação do CUR](https://docs.aws.amazon.com/cur/latest/userguide/use-cases.html)) e selecionar as colunas que são relevantes somente para você. Cada chave de tag ativada para alocação de custos será apresentada em sua própria coluna separada no final do relatório CUR, da mesma forma que é apresentada em outros relatórios de faturamento antigos, como o relatório [mensal de alocação de custos](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/configurecostallocreport.html). Para referência adicional, consulte [AWS Well-Architected Labs](https://www.wellarchitectedlabs.com/cost/300_labs/300_cur_queries/) para ver exemplos de como obter insights de custo e uso dos dados do CUR. 

## Relatórios
<a name="reporting-charges"></a>

 Além das AWS ferramentas disponíveis para ajudar com reembolsos e estornos, há uma variedade de outras soluções AWS criadas e de terceiros que podem ajudar a monitorar o custo dos recursos etiquetados e medir a eficácia da estratégia de marcação. Dependendo dos requisitos e do objetivo final da organização, pode-se investir tempo e recursos na criação de soluções personalizadas ou na compra de ferramentas fornecidas por um dos [parceiros com competência em ferramentas de gerenciamento da Nuvem AWS](https://aws.amazon.com/products/management-tools/partner-solutions/?partner-solutions-cards.sort-by=item.additionalFields.partnerNameLower&partner-solutions-cards.sort-order=asc&awsf.partner-solutions-filter-partner-type=%2Aall&awsf.Filter%20Name%3A%20partner-solutions-filter-partner-use-case=%2Aall&awsf.partner-solutions-filter-partner-location=%2Aall). Se você decidir criar sua própria ferramenta de alocação de custos *de fonte* fidedigna com parâmetros controlados relevantes para a empresa, o Relatório de AWS Custo e Uso (CUR) fornece os dados mais detalhados de custo e uso e permite a criação de painéis de otimização personalizados, permitindo filtrar e agrupar por contas, serviços, categorias de custo, etiquetas de alocação de custos e várias outras dimensões. Entre as soluções baseadas em CUR desenvolvidas pela AWS that podem ser usadas como uma dessas ferramentas, confira o [Cloud Intelligence Dashboards](https://www.wellarchitectedlabs.com/cost/200_labs/200_cloud_intelligence/) no site da Well-Architected AWS Labs. 

# Tags para operações e suporte
<a name="tags-for-operations-and-support"></a>

 Um AWS ambiente terá várias contas, recursos e cargas de trabalho com diferentes requisitos operacionais. As tags podem ser usadas para fornecer contexto e orientação para apoiar as equipes de operações a fim de aprimorar o gerenciamento de seus serviços. As tags também podem ser usadas para fornecer transparência na governança operacional dos recursos gerenciados. 

 Alguns dos principais fatores que impulsionam a definição consistente de tags operacionais são: 
+  **Para filtrar recursos durante atividades de infraestrutura automatizada.** Por exemplo, ao implantar, atualizar ou excluir recursos. Outra é a escalabilidade de recursos para otimização de custos e reduções de uso fora do horário de expediente. Consulte a solução [AWS Instance Scheduler](https://aws.amazon.com/solutions/implementations/instance-scheduler/) para obter um exemplo de trabalho. 
+  **Identificação de recursos isolados ou obsoletos.** Os recursos que excederam sua vida útil definida ou foram sinalizados para isolamento por mecanismos internos devem ser marcados adequadamente para auxiliar o pessoal de suporte em sua investigação. Os recursos obsoletos devem ser marcados antes do isolamento, arquivamento e exclusão. 
+  **Requisitos de suporte para um grupo de recursos.** Os recursos geralmente têm requisitos de suporte diferentes; por exemplo, esses requisitos podem ser negociados entre equipes ou definidos como parte da criticidade de uma aplicação. Mais orientações sobre modelos operacionais podem ser encontradas no [Pilar Excelência operacional](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/operating-model.html). 
+  **Melhore o processo de gerenciamento de incidentes.** Ao marcar recursos com tags que oferecem maior transparência no processo de gerenciamento de incidentes, as equipes de suporte e os engenheiros, bem como as equipes de gerenciamento de incidentes graves (MIM), podem gerenciar eventos com maior eficiência. 
+  **Backups.** As tags também podem ser usadas para identificar a frequência com que seus recursos precisam ser copiados e para onde as cópias de backup precisam ir ou para onde restaurá-las. [Orientação prescritiva para abordagens de backup e recuperação](https://docs.aws.amazon.com/prescriptive-guidance/latest/backup-recovery/welcome.html) sobre. AWS
+  **Aplicação de patches.** A correção de instâncias mutáveis em execução AWS é crucial tanto em sua estratégia abrangente de patches quanto na correção de vulnerabilidades de dia zero. Orientações mais detalhadas sobre a estratégia mais ampla de aplicação de patches podem ser encontradas na orientação [prescritiva](https://docs.aws.amazon.com/prescriptive-guidance/latest/patch-management-hybrid-cloud/welcome.html). [A correção de vulnerabilidades de dia zero é discutida neste blog.](https://aws.amazon.com/blogs/mt/avoid-zero-day-vulnerabilities-same-day-security-patching-aws-systems-manager/) 
+  **Observabilidade operacional**. Ter uma estratégia de KPI operacional traduzida em tags de recursos ajudará as equipes de operações a monitorar melhor se as metas estão sendo cumpridas para aprimorar os requisitos de negócios. Desenvolver uma estratégia de KPI é um tópico separado, mas tende a se concentrar em uma empresa que opera em um estado estável ou onde medir o impacto e os resultados da mudança. Os [KPI Dashboards](https://wellarchitectedlabs.com/cost/200_labs/200_cloud_intelligence/cost-usage-report-dashboards/dashboards/2c_kpi_dashboard/) (AWS Well-Architected labs) e o Operations KPI Workshop (um serviço [proativo do AWS Enterprise Support](https://aws.amazon.com/premiumsupport/technology-and-programs/proactive-services/)) abordam a medição do desempenho em um estado estável. O artigo do blog de estratégia AWS corporativa [Measuring the Success of Your Transformation](https://aws.amazon.com/blogs/enterprise-strategy/measuring-the-success-of-your-transformation/) explora a medição de KPI para um programa de transformação, como a modernização da TI ou a migração do local para o. AWS

# Automação de infraestrutura
<a name="automated-infrastructure-activities"></a>

 As tags podem ser usadas em uma ampla variedade de atividades de automação ao gerenciar a infraestrutura. O uso do [AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/index.html), por exemplo, permitirá que você gerencie automações e runbooks em recursos especificados pelo par de chave-valor definido que você criar. Para nós gerenciados, você pode definir um conjunto de tags para rastrear ou direcionar nós por sistema operacional e ambiente. Em seguida, você pode executar um script de atualização para todos os nós em um grupo ou revisar o status desses nós. Os [Recursos do Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/taggable-resources.html) também podem ser marcados para refinar e rastrear ainda mais suas atividades automatizadas. 

 Automatizar o ciclo de vida inicial e final dos recursos do ambiente pode proporcionar uma redução significativa de custos para qualquer organização. O [Instance Scheduler na AWS](https://aws.amazon.com/solutions/implementations/instance-scheduler/) é um exemplo de solução que pode iniciar e interromper instâncias do Amazon EC2 e do Amazon RDS quando elas não são necessárias. Por exemplo, ambientes de desenvolvedores que utilizam instâncias do Amazon EC2 ou do Amazon RDS que não precisam ser executadas nos finais de semana não estão utilizando o potencial de redução de custos que o encerramento dessas instâncias pode oferecer. Ao analisar as necessidades das equipes e de seus ambientes e marcar adequadamente esses recursos para automatizar seu gerenciamento, você pode utilizar seu orçamento de forma eficaz. 

 *Um exemplo de tag de agendamento usada pelo agendador de instâncias em uma instância do Amazon EC2:* 

```
{
    "Tags": [
        {
            "Key": "Schedule",
            "ResourceId": "i-1234567890abcdef8",
            "ResourceType": "instance",
            "Value": "mon-9am-fri-5pm"
        }
    ]
}
```

# Ciclo de vida da workload
<a name="workload-lifecycle"></a>

**Analise a precisão dos dados operacionais de suporte.** Certifique-se de que haja análises periódicas das tags associadas ao ciclo de vida da workload e que as partes interessadas apropriadas estejam envolvidas nessas análises. 

 *Tabela 7: Análise das tags operacionais como parte do ciclo de vida da workload* 


|  Caso de uso  |  Chave de tag  |  Lógica  |  Valores de exemplo  | 
| --- | --- | --- | --- | 
|  Proprietário da conta  | example-inc:account-owner:owner  |  O proprietário da conta e seus recursos contidos.  | ops-center, dev-ops, app-team  | 
|  Revisão do proprietário da conta  | example-inc:account-owner:review  |  Análise de que os detalhes de propriedade da conta estão atualizados e corretos.  | <review date in the correct format defined in your tagging library>  | 
|  ID de usuário  | example-inc:data-owner:owner  |  O proprietário dos dados das contas que residem nos dados.  | bi-team, logistics, security  | 
|  Analisar o proprietário  | example-inc:data-owner:review  |  Revisão dos detalhes de propriedade dos dados que estão atualizados e corretos.  | <review date in the correct format defined in your tagging library>  | 

## Atribuição de tags às contas suspensas antes de migrar para a UO suspensa
<a name="assigning-tags-to-suspending-accounts"></a>

 Antes de suspender uma conta e passar para a OU suspensa, conforme detalhado no whitepaper [Organizando seu AWS ambiente usando várias contas](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/organizing-your-aws-environment.html), as tags devem ser adicionadas à conta para ajudar no rastreamento interno e na auditoria do ciclo de vida de uma conta. Por exemplo, um URL relativo ou uma referência de tíquete no sistema de tíquetes ITSM de uma organização, que mostra a trilha de auditoria de uma aplicação que está sendo suspensa. 

 *Tabela 8: Adição de tags operacionais quando o ciclo de vida da workload entrar em um novo estágio* 


|  Caso de uso  |  Chave de tag  |  Lógica  |  Valores de exemplo  | 
| --- | --- | --- | --- | 
|  Proprietário da conta  | example-inc:account-owner:owner  |  O proprietário da conta e seus recursos contidos.  | ops-center, dev-ops, app-team  | 
|  ID de usuário  | example-inc:data-owner:owner  |  O proprietário dos dados das contas que residem nos dados.  | bi-team, logistics, security  | 
|  Data de suspensão  | example-inc:suspension:date  |  A data em que a conta foi suspensa  |  <suspended date in the correct format defined in your tagging library>  | 
|  Aprovação para suspensão  | example-inc:suspension:approval  |  O link para a aprovação da suspensão da conta  | workload/deprecation  | 

# Gerenciamento de incidentes
<a name="incident-management"></a>

 As tags podem desempenhar um papel vital em todas as fases do gerenciamento de incidentes, desde o registro em log de incidentes, a priorização, a investigação, a comunicação e a resolução até o encerramento. 

 As tags podem detalhar onde um incidente deve ser registrado em log, a equipe ou equipes que devem ser informadas sobre o incidente e a prioridade de encaminhamento definida. É importante lembrar que as tags não são criptografadas, então considere quais informações você armazena nelas. Além disso, em organizações, equipes e linhas de relatórios, as responsabilidades mudam, então considere armazenar um link para um portal seguro onde essas informações possam ser gerenciadas com mais eficiência. Ao especificar a política, tenha em mente as considerações e limitações. Por exemplo, o ID da aplicação pode ser usado para pesquisar os caminhos de encaminhamento em um portal de gerenciamento de serviços de TI. Certifique-se de que esteja claro em suas definições operacionais que essa tag está sendo usada para várias finalidades. 

 As tags de requisitos operacionais também podem ser detalhadas para ajudar os gerentes de incidentes e a equipe de operações a refinar ainda mais seus objetivos em resposta a um incidente ou evento. 

 Links relativos (para o URL base do sistema de conhecimento) para [runbooks](https://wa.aws.amazon.com/wellarchitected/2020-07-02T19-33-23/wat.concept.runbook.en.html) e [manuais](https://wa.aws.amazon.com/wellarchitected/2020-07-02T19-33-23/wat.concept.playbook.en.html) podem ser incluídos como tags para ajudar as equipes respondentes a identificar o processo, o procedimento e a documentação correspondentes. 

 *Tabela 9: Uso de tags operacionais para informar o gerenciamento de incidentes* 


|  Caso de uso  |  Chave de tag  |  Lógica  |  Valores de exemplo  | 
| --- | --- | --- | --- | 
|  Gerenciamento de incidentes  | example-inc:incident-management:escalationlog  |  O sistema em uso pela equipe de suporte para registrar incidentes  | jira, servicenow, zendesk  | 
|  Gerenciamento de incidentes  | example-inc:incident-management:escalationpath  |  Caminho de escalação  | ops-center, dev-ops, app-team  | 
|  Alocação de custos e gerenciamento de incidentes  | example-inc:cost-allocation:CostCenter |  Monitore os custos por centro de custo. Este é um exemplo de uma tag de uso duplo em que o centro de custos está sendo usado como um código de aplicação para registro em log de incidentes  | 123-\$1  | 
|  Programação de backup  | example-inc:backup:schedule  |  Programação de backup do recurso  | Daily  | 
|  Manual/gerenciamento de incidentes  | example-inc:incident-management:playbook  |  Manual documentado  | webapp/incident/playbook  | 

# Aplicação de patches
<a name="patching"></a>

 As organizações podem automatizar sua estratégia de aplicação de patches para ambientes de computação mutáveis e manter as instâncias mutáveis alinhadas com a lista de referência de patches definida desse ambiente de aplicação usando o Gerenciador de Patches do AWS Systems Manager e o AWS Lambda. Uma estratégia de marcação para instâncias mutáveis nesses ambientes pode ser gerenciada atribuindo essas instâncias a **grupos de patches** e **janelas de manutenção**. Veja os exemplos a seguir para uma divisão Dev → Test → Prod. AWS uma orientação prescritiva está disponível para o [gerenciamento de patches de instâncias mutáveis](https://docs.aws.amazon.com/prescriptive-guidance/latest/patch-management-hybrid-cloud/welcome.html). 

 *Tabela 10: As tags operacionais podem ser específicas do ambiente* 


|  Desenvolvimento  |  Preparação  |  Produção  | 
| --- | --- | --- | 
|  <pre>{<br />"Tags": [<br />{<br />"Key": "Maintenance Window",<br />"ResourceId": "i-012345678ab9ab111",<br />"ResourceType": "instance",<br />"Value": "cron(30 23 ? * TUE#1 *)"<br />},<br />{<br />"Key": "Name",<br />"ResourceId": "i-012345678ab9ab222",<br />"ResourceType": "instance",<br />"Value": "WEBAPP"<br />},<br />{<br />"Key": "Patch Group",<br />"ResourceId": "i-012345678ab9ab333",<br />"ResourceType": "instance",<br />"Value": "WEBAPP-DEV-AL2"<br />}<br />]<br />}<br /></pre>  |  <pre>{<br />"Tags": [<br />{<br />"Key": "Maintenance Window",<br />"ResourceId": "i-012345678ab9ab444",<br />"ResourceType": "instance",<br />"Value": "cron(30 23 ? * TUE#2 *)"<br />},<br />{<br />"Key": "Name",<br />"ResourceId": "i-012345678ab9ab555",<br />"ResourceType": "instance",<br />"Value": "WEBAPP"<br />},<br />{<br />"Key": "Patch Group",<br />"ResourceId": "i-012345678ab9ab666",<br />"ResourceType": "instance",<br />"Value": "WEBAPP-TEST-AL2"<br />}<br />]<br />}<br /></pre>  |  <pre>{<br />"Tags": [<br />{<br />"Key": "Maintenance Window",<br />"ResourceId": "i-012345678ab9ab777",<br />"ResourceType": "instance",<br />"Value": "cron(30 23 ? * TUE#3 *)"<br />},<br />{<br />"Key": "Name",<br />"ResourceId": "i-012345678ab9ab888",<br />"ResourceType": "instance",<br />"Value": "WEBAPP"<br />},<br />{<br />"Key": "Patch Group",<br />"ResourceId": "i-012345678ab9ab999",<br />"ResourceType": "instance",<br />"Value": "WEBAPP-PROD-AL2"<br />}<br />]<br />}<br /></pre>  | 

 As vulnerabilidades de dia zero também podem ser gerenciadas com tags definidas para complementar sua estratégia de patches. Consulte [Evite vulnerabilidades de dia zero com patches de segurança no mesmo dia usando o Systems AWS Manager](https://aws.amazon.com/blogs/mt/avoid-zero-day-vulnerabilities-same-day-security-patching-aws-systems-manager/) para obter orientação detalhada. 

# Observabilidade operacional.
<a name="operational-observability"></a>

 A observabilidade é necessária para obter insights acionáveis sobre o desempenho de seus ambientes e ajudá-lo a detectar e investigar problemas. Ele também tem uma finalidade secundária que permite definir e medir os principais indicadores de desempenho (KPIs) e objetivos de nível de serviço (SLOs), como tempo de atividade. Para a maioria das organizações, operações importantes KPIs são o tempo médio de detecção (MTTD) e o tempo médio de recuperação (MTTR) de um incidente. 

Em toda a observabilidade, o contexto é importante, porque os dados são coletados e, em seguida, as tags associadas são coletadas. Independentemente do serviço, aplicação ou nível de aplicação em que você está se concentrando, você pode filtrar e analisar esse conjunto de dados específico. As tags podem ser usadas para automatizar a integração de CloudWatch alarmes, para que as equipes certas possam ser alertadas quando determinados limites métricos forem violados. Por exemplo, uma chave de tag `example-inc:ops:alarm-tag` e o valor nela podem indicar a criação do CloudWatch alarme. Uma solução que demonstra isso está descrita em [Use tags para criar e manter CloudWatch alarmes da Amazon para instâncias do Amazon EC2](https://aws.amazon.com/blogs/mt/use-tags-to-create-and-maintain-amazon-cloudwatch-alarms-for-amazon-ec2-instances-part-1/).

 Ter muitos alarmes configurados pode criar facilmente uma tempestade de alertas, quando um grande número de alarmes ou notificações sobrecarrega rapidamente os operadores e reduz sua eficácia geral, enquanto os operadores fazem a triagem e priorizam manualmente os alarmes individuais. Um contexto adicional para os alarmes pode ser fornecido na forma de tags, o que significa que as regras podem ser definidas na Amazon EventBridge para ajudar a garantir que o foco seja dado ao problema inicial, e não às dependências posteriores. 

 O papel das operações paralelas geralmente DevOps é negligenciado, mas para muitas organizações, as equipes de operações centrais ainda fornecem uma primeira resposta crítica fora do horário comercial normal. (Mais detalhes sobre esse modelo podem ser encontrados no [whitepaper de Excelência operacional](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/separated-aeo-ieo-with-cent-gov-and-partner.html).) [Diferentemente da DevOps equipe responsável pela carga de trabalho, ela normalmente não tem a mesma profundidade de conhecimento. Portanto, o contexto que as tags fornecem nos painéis e alertas pode direcioná-las para o runbook correto para o problema ou iniciar um runbook automatizado (consulte a postagem do blog Automatizando os alarmes da Amazon com). CloudWatch AWS Systems Manager](https://aws.amazon.com/blogs/mt/automating-amazon-cloudwatch-alarms-with-aws-systems-manager/) 

# Tags para segurança de dados, gerenciamento de riscos e controle de acesso
<a name="tags-for-data-security-risk-management-and-access-control"></a>

 As organizações têm necessidades e obrigações variadas a cumprir em relação ao tratamento adequado do armazenamento e processamento de dados. A classificação de dados é um precursor importante para vários casos de uso, como controle de acesso, retenção de dados, análise de dados e conformidade. 

# Segurança de dados e gerenciamento de riscos
<a name="data-security-and-risk-management"></a>

Em um AWS ambiente, você provavelmente terá contas com diferentes requisitos de conformidade e segurança. Por exemplo, você pode ter um sandbox para desenvolvedores e uma conta hospedando o ambiente de produção para uma workload altamente regulamentada, como processamento de pagamentos. Ao isolá-los em contas diferentes, é possível [aplicar controles de segurança distintos](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/benefits-of-using-multiple-aws-accounts.html#apply-distinct-security-controls-by-environment), [restringir o acesso a dados confidenciais](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/benefits-of-using-multiple-aws-accounts.html#constrain-access-to-sensitive-data) e reduzir o escopo da auditoria para workloads regulamentadas. 

 A adoção de um padrão único para todas workloads pode gerar desafios. Embora muitos controles se apliquem igualmente em um ambiente, alguns são excessivos ou irrelevantes para contas que não precisam atender a estruturas regulatórias específicas e contas em que nenhum dado pessoal identificável estará presente (por exemplo, um sandbox para desenvolvedores ou contas de desenvolvimento de workload). Isso normalmente leva a descobertas de segurança falsas positivas que devem ser triadas e encerradas sem nenhuma ação, o que retira o esforço das descobertas que devem ser investigadas. 

 *Tabela 11: Exemplos de tags de segurança de dados e gerenciamento de riscos* 


|  Caso de uso  |  Chave de tag  |  Lógica  |  Valores de exemplo  | 
| --- | --- | --- | --- | 
| Gerenciamento de incidentes  | example-inc:incident- management:escalationlog |  O sistema em uso pela equipe de suporte para registrar incidentes  |  jira, servicenow, zendesk  | 
| Gerenciamento de incidentes  | example-inc:incident- management:escalationpath |  Caminho de escalação  | ops-center, dev-ops, app-team  | 
| Classificação de dados  | example-inc:data:classification |  Classifique os dados para fins de conformidade e governança  | Public, Private, Confidential, Restricted  | 
| Compliance  | example-inc:compliance:framework |  Identifica a estrutura de conformidade à qual a workload está sujeita  | PCI-DSS, HIPAA  | 

 O gerenciamento manual de diferentes controles em um AWS ambiente é demorado e propenso a erros. A próxima etapa é automatizar a implantação dos controles de segurança apropriados e configurar a inspeção dos recursos com base na classificação dessa conta. Ao aplicar tags às contas e aos recursos dentro delas, a implantação de controles pode ser automatizada e configurada adequadamente para a workload. 

**Exemplo: **

 Uma workload inclui um bucket do Amazon S3 com a tag `example-inc:data:classification` e o valor `Private`. A automação das ferramentas de segurança implanta a AWS Config regra`s3-bucket-public-read-prohibited`, que verifica as configurações de bloqueio de acesso público do bucket Amazon S3, a política do bucket e a lista de controle de acesso (ACL) do bucket, confirmando que a configuração do bucket é apropriada para sua classificação de dados. Para garantir que o conteúdo do bucket seja consistente com a classificação, o [Amazon Macie pode ser configurado para verificar as informações de identificação pessoal](https://aws.amazon.com/about-aws/whats-new/2021/05/amazon-macie-supports-criteria-based-bucket-selection-sensitive-data-discovery-jobs/) (PII). O blog [Using Amazon Macie to Validate S3 Bucket Data Classification](https://aws.amazon.com/blogs/architecture/using-amazon-macie-to-validate-s3-bucket-data-classification/) explora esse padrão com mais profundidade. 

 Certos ambientes regulatórios, como seguros e assistência médica, podem estar sujeitos a políticas obrigatórias de retenção de dados. A retenção de dados usando tags, combinada com as políticas de ciclo de vida do Amazon S3, pode ser uma forma eficaz e simples de definir o escopo das transições de objetos para um nível de armazenamento diferente. As regras de ciclo de vida do Amazon S3 também podem ser usadas para expirar objetos para exclusão de dados após o término do período de retenção obrigatório. Consulte [Simplify your data lifecycle by using object tags with Amazon S3 Lifecycle](https://aws.amazon.com/blogs/storage/simplify-your-data-lifecycle-by-using-object-tags-with-amazon-s3-lifecycle/) para obter um guia detalhado desse processo. 

 Além disso, ao fazer a triagem ou abordar as descobertas de segurança, as tags podem fornecer ao investigador um contexto importante que ajuda a qualificar o risco e ajuda a engajar as equipes apropriadas para investigar ou mitigar a descoberta. 

# Tags para gerenciamento de identidade e controle de acesso
<a name="tags-for-identity-management-and-access-control"></a>

 Ao gerenciar o controle de acesso em um AWS ambiente com Centro de Identidade do AWS IAM, as tags podem habilitar vários padrões de escalabilidade. Existem vários padrões de delegação que podem ser aplicados, alguns são baseados na marcação. Nós os abordaremos individualmente e forneceremos links para leituras adicionais sobre cada um. 

# ABAC recursos individuais
<a name="abac-for-individual-resources"></a>

 Os perfis do IAM e os usuários do Centro de Identidade do IAM comportam controle de acesso por atributo (ABAC), que permite definir o acesso a operações e recursos com base em tags. O ABAC ajuda a reduzir a necessidade de atualizar as políticas de permissão e ajuda você a basear o acesso nos atributos dos funcionários do seu diretório corporativo. Se você já estiver usando uma estratégia de várias contas, o ABAC pode ser usado além do controle de acesso baseado em funções (RBAC) para fornecer a várias equipes que operam na mesma conta acesso granular a diferentes recursos. Por exemplo, perfis do IAM ou usuários do Centro de Identidade do IAM podem incluir condições para limitar o acesso a instâncias específicas do Amazon EC2 que, de outra forma, precisariam ser listadas explicitamente em cada política para acessá-las. 

 Como um modelo de autorização ABAC depende de tags para acesso às operações e aos recursos, é importante fornecer grades de proteção para evitar o acesso não intencional. SCPs pode ser usado para proteger as tags em toda a sua organização, permitindo que as tags sejam modificadas somente sob determinadas condições. Os blogs [Securing resource tags used for authorization using a service control policy in AWS Organizations](https://aws.amazon.com/blogs/security/securing-resource-tags-used-for-authorization-using-service-control-policy-in-aws-organizations/) e [Permissions boundaries for IAM entities](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html) fornecem informações sobre como implementar isso. 

 No caso que instâncias de longa duração do Amazon EC2 estão sendo usadas para atender a práticas operacionais mais tradicionais, essa abordagem pode ser utilizada. O blog [Configure IAM Identity Center ABAC for Amazon EC2 instances and Systems Manager Session Manager](https://aws.amazon.com/blogs/security/configure-aws-sso-abac-for-ec2-instances-and-systems-manager-session-manager/) discute essa forma de controle de acesso baseado em atributos com mais detalhes. Conforme mencionado anteriormente, nem todos os tipos de recursos oferecem suporte à marcação e, dos que oferecem, nem todos oferecem suporte à fiscalização usando políticas de tags. Portanto, é uma boa ideia avaliar isso antes de começar a implementar essa estratégia em uma Conta da AWS.

Para saber mais sobre os serviços que oferecem suporte ao ABAC, consulte [serviços AWS que funcionam com o IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html).