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á. # Criar política de tag Como acontece com muitas práticas em operações, a implementação de uma estratégia de marcação é *um processo de iteração e aprimoramento*. Comece aos poucos, com sua prioridade imediata e aumente o esquema de marcação conforme necessário. ![\[Diagrama mostrando uma representação gráfica da estratégia de marcação, iteração e ciclo de melhoria\]](http://docs.aws.amazon.com/pt_br/whitepapers/latest/tagging-best-practices/images/tagging-strategy-cycle.png) Durante todo esse processo, a propriedade é fundamental para a responsabilidade e o progresso. Como as tags podem ser usadas para diversas finalidades, a estratégia geral de marcação pode ser dividida em áreas de responsabilidade dentro de uma organização. A marcação permite uma abordagem programática de atividades que dependem da caracterização dos recursos. A variedade de partes interessadas que podem se beneficiar da marcação dependerá do tamanho da organização e das práticas operacionais. Organizações maiores podem se beneficiar da definição clara das responsabilidades das equipes envolvidas na criação e implementação de uma estratégia de marcação. Algumas partes interessadas podem ser responsáveis por identificar as necessidades (definir casos de uso) de marcação; outras podem ser responsáveis por manter, implementar e melhorar a estratégia de marcação. Ao atribuir a propriedade, você está em uma boa posição para implementar aspectos individuais da estratégia. Quando apropriado, essa propriedade pode ser formalizada como política e documentada em uma matriz de responsabilidade (por exemplo, RACI: Responsável, Responsabilizado, Consultado e Informado) ou em um modelo de responsabilidade compartilhada. Em organizações menores, as equipes podem desempenhar várias funções em uma estratégia de marcação, desde a definição dos requisitos até a implementação e a fiscalização. # Definir necessidades e casos de uso Comece a criar sua estratégia interagindo com as partes interessadas que têm uma necessidade fundamental subjacente de consumir metadados. Essas equipes definem os metadados com os quais os recursos precisam ser marcados para apoiar suas atividades, como relatórios, automação e classificação de dados. Eles descrevem como os recursos precisam ser organizados e para quais políticas eles precisam ser mapeados. Exemplos de papéis e funções que essas partes interessadas podem ter nas organizações incluem: + O **financeiro** e a **linha de negócios** precisam entender o valor do investimento associando-o aos custos para priorizar as ações que precisam ser executadas ao lidar com a ineficiência. Entender o *custo versus o valor gerado* ajuda a identificar linhas de negócios ou ofertas de produtos malsucedidas. Isso leva a decisões informadas sobre suporte contínuo, adoção de uma alternativa (por exemplo, uso de uma oferta de SaaS ou serviço gerenciado) ou retirada de uma oferta comercial não lucrativa. + A **governança** e a **conformidade** precisam entender a categorização dos dados (por exemplo, públicos, sigilosos ou confidenciais), se uma workload específica está dentro ou fora do escopo da auditoria em relação a um padrão ou regulamento específico e a importância do serviço (se o serviço ou a aplicação é essencial para os negócios) para aplicar controles e supervisão adequados, como permissões, políticas e monitoramento. + As **operações** e o **desenvolvimento** precisam entender o ciclo de vida da workload, os estágios implementados de seus produtos compatíveis e o gerenciamento dos estágios de lançamento (por exemplo, desenvolvimento, teste, divisão de produção) e suas priorizações de suporte associadas e requisitos de gerenciamento de partes interessadas. Deveres como backups, aplicação de patches, observabilidade e suspensão de uso também precisam ser definidos e compreendidos. + A **Segurança da Informação (InfoSec)** e **as Operações de Segurança (SecOps)** descrevem quais controles devem ser aplicados e quais são recomendados. InfoSec normalmente define a implementação dos controles e geralmente SecOps é responsável por gerenciar esses controles. Dependendo do seu caso de uso, das prioridades, do tamanho da sua organização e das práticas operacionais, você pode precisar da representação de várias equipes dentro da organização, como finanças (incluindo compras), segurança da informação, capacitação da nuvem e operações na nuvem. Você também precisa da representação dos proprietários de aplicações e processos para funções como aplicação de patches, backup e restauração, monitoramento, agendamento de tarefas e recuperação de desastres. Esses representantes ajudam a orientar a definição, a implementação e a medir a eficácia da estratégia de marcação. Eles devem [https://www.youtube.com/watch?v=aFdpBqmDpzM](https://www.youtube.com/watch?v=aFdpBqmDpzM) com as partes interessadas e seus casos de uso e conduzir um workshop multifuncional. No workshop, eles têm a chance de compartilhar suas perspectivas e necessidades e ajudar a impulsionar uma estratégia geral. Exemplos de participantes e seu envolvimento em vários casos de uso são descritos posteriormente neste whitepaper. As partes interessadas também definem e validam as chaves para as tags obrigatórias e podem recomendar o escopo das tags opcionais. Por exemplo, as equipes financeiras podem precisar relacionar um recurso a um centro de custos interno, a uma unidade de negócios ou a ambos. Assim, eles podem exigir que certas chaves de tag, como `CostCenter` e`BusinessUnit`, sejam tornadas obrigatórias. As equipes de desenvolvimento individuais podem decidir usar tags adicionais para fins de automação, como `EnvironmentName`, `OptIn` ou `OptOut`. As principais partes interessadas precisam concordar com a abordagem da estratégia de marcação e documentar as respostas para questões relacionadas à conformidade e à governança, como: + Quais casos de uso precisam ser abordados? + Quem é responsável por marcar recursos (implementação)? + Como as tags são aplicadas e quais métodos e automação serão usados (proativos ou reativos)? + Como a eficácia e as metas da marcação são medidas? + Com que frequência a estratégia de marcação deve ser revisada? + Quem impulsiona as melhorias? Como isso é feito? Funções de negócios, como capacitação de nuvem, escritório de negócios em nuvem e engenharia de plataforma em nuvem, podem então desempenhar o papel de facilitadoras do processo de criação da estratégia de marcação, ajudar a impulsionar sua adoção e garantir a consistência de sua aplicação medindo o progresso, removendo obstáculos e reduzindo o esforço duplicado. # Definir e publicar um esquema de marcação Use uma abordagem consistente para marcar seus AWS recursos, tanto para tags obrigatórias quanto opcionais. Um esquema abrangente de marcação ajuda você a alcançar essa consistência. Os exemplos a seguir podem ajudá-lo a começar: + Concorde com as chaves de tag obrigatórias + Defina valores aceitáveis e convenções de nomenclatura de tags (letras maiúsculas ou minúsculas, traços ou sublinhados, hierarquia etc.) + Confirmar que os valores não constituiriam informações de identificação pessoal (PII) + Decidir quem pode definir e criar novas chaves de tag + Chegue a um acordo sobre como adicionar novos valores de tag obrigatórios e como gerenciar tags opcionais Analise a tabela de [categorias de marcação](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html) a seguir, que pode ser usada como base do que você pode incluir em seu esquema de marcação. Você ainda precisa determinar a convenção que usará para a chave da tag e quais valores são permitidos para cada uma. O esquema de marcação é o documento no qual você define isso para seu ambiente. *Tabela 6: Exemplo de um esquema de marcação definitivo* | Caso de uso | Chave de tag | Lógica | Valores permitidos (listados ou prefixo de valor/suv/x) | Usado para alocação de custos | Tipos de recursos | Escopo | Obrigatório | | --- | --- | --- | --- | --- | --- | --- | --- | | Alocação de custos | example-inc:cost-allocation:ApplicationId | Acompanhe o custo versus o valor gerado por cada linha de negócios | DataLakeX, RetailSiteX | S | Todos | Todos | Obrigatório | | Alocação de custos | example-inc:cost-allocation:BusinessUnitId | Monitore os custos por unidade de negócios | Architecture, DevOps, Finance | S | Todos | Todos | Obrigatório | | Alocação de custos | example-inc:cost-allocation:CostCenter | Monitore os custos por centro de custo | 123-\$1 | S | Todos | Todos | Obrigatório | | Alocação de custos | example-inc:cost-allocation:Owner | Qual detentor do orçamento é responsável por essa workload | Marketing, RetailSupport | S | Todos | Todos | Obrigatório | | Controle de acesso | example-inc:access-control:LayerId | Identifique SubComponent /Layer para conceder acesso aos recursos com base na função | DB\$1Layer, Web\$1Layer, App\$1Layer | N | Todos | Todos | Opcional | | Automação | example-inc:automation:EnvironmentId | Implemente o agendamento de ambientes de teste e desenvolvimento, também conhecido como estágio do ciclo de vida de desenvolvimento de software (SDLC) | Prod, Dev, Test, Sandbox | N | EC2, RDS, EBS | Todos | Obrigatório | | DevOps | example-inc:operations:Owner | Que team/squad é responsável pela criação e manutenção do recurso | Squad01 | N | Todos | Todos | Obrigatório | | Recuperação de desastres | example-inc:disaster-recovery:rpo | Defina o objetivo de ponto de recuperação (RPO) para um recurso | 6h, 24h | N | S3, EBS | Prod | Obrigatório | | Classificação de dados | example-inc:data:classification | Classifique os dados para fins de conformidade e governança | Public, Private, Confidential, Restricted | N | S3, EBS | Todos | Obrigatório | | Compliance | example-inc:compliance:framework | Identifica a estrutura de conformidade à qual a workload está sujeita | PCI-DSS, HIPAA | N | Todos | Prod | Obrigatório | Depois que o esquema de marcação for definido, gerencie o esquema em um repositório com controle de versão que seja acessível a todas as partes interessadas relevantes para facilitar a consulta e as atualizações rastreáveis. Essa abordagem melhora a eficiência e permite agilidade. # AWS Organizations — Políticas de tags As políticas AWS Organizations permitem que você aplique tipos adicionais de governança Contas da AWS em sua organização. Uma [https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_tag-policies.html](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_tag-policies.html) é como você pode expressar seu esquema de marcação no formato JSON para que a plataforma possa relatar e, opcionalmente, aplicar o esquema em seu ambiente. AWS A política de tags define os valores que são aceitáveis para uma chave de tag em tipos de recursos específicos. Essa política pode ter a forma de uma lista de valores ou de um prefixo seguido por um caractere curinga (`*`). A abordagem de prefixo simples é menos rigorosa do que uma lista discreta de valores, mas requer menos manutenção. Os exemplos a seguir mostram como definir uma política de marcação para validar os valores que são aceitáveis para uma determinada chave. Trabalhando com a definição tabular amigável do esquema, você pode transcrever essas informações em uma ou mais políticas de tag. Políticas separadas podem ser usadas para apoiar a propriedade delegada ou algumas políticas podem ser aplicadas somente em cenários específicos. ## ExampleInc- CostAllocation .json A seguir, um exemplo de política de tag que informa sobre tags de alocação de custos: ``` { "tags": { "example-inc:cost-allocation:ApplicationId": { "tag_key": { "@@assign": "example-inc:cost-allocation:ApplicationId" }, "tag_value": { "@@assign": [ "DataLakeX", "RetailSiteX" ] } }, "example-inc:cost-allocation:BusinessUnitId": { "tag_key": { "@@assign": "example-inc:cost-allocation:BusinessUnitId" }, "tag_value": { "@@assign": [ "Architecture", "DevOps", "FinanceDataLakeX" ] } }, "example-inc:cost-allocation:CostCenter": { "tag_key": { "@@assign": "example-inc:cost-allocation:CostCenter" }, "tag_value": { "@@assign": [ "123-*" ] } } } } ``` ## ExampleInc- DisasterRecovery .json Veja a seguir um exemplo de uma política de tags que relata as tags de recuperação de desastres. ``` { "tags": { "example-inc:disaster-recovery:rpo": { "tag_key": { "@@assign": "example-inc:disaster-recovery:rpo" }, "tag_value": { "@@assign": [ "6h", "24h" ] } } } } ``` Neste exemplo, a política de `ExampleInc-CostAllocation` tags é anexada à `Workloads` OU e, portanto, se aplica a todas as contas da UO `Prod` e da conta `Test` secundária OUs. Da mesma forma, a política de tag `ExampleInc-DisasterRecovery` é anexada à UO `Prod` e, portanto, aplica-se somente a contas abaixo dessa UO. O whitepaper [Organizing Your Environment Using Multiple Accounts](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/organizing-your-aws-environment.html) explora as estruturas de UO recomendadas com mais detalhes. ![\[Diagrama mostrando a vinculação das políticas de tag a uma estrutura de UO e a política efetiva\]](http://docs.aws.amazon.com/pt_br/whitepapers/latest/tagging-best-practices/images/adding-tagging-to-policies-in-ou-structure.png) Observando a conta `marketing-prod` no diagrama, as duas políticas de tag se aplicam a essa conta, então temos o conceito de uma *política efetiva*, que é a convolução das políticas de um determinado tipo que se aplicam a uma conta. Se você gerencia principalmente seus recursos manualmente, pode revisar a política efetiva visitando [Resource Groups & Tag Editor:Tag policies no console](https://console.aws.amazon.com/resource-groups/tag-policies). Se você usa infraestrutura como código (IaC) ou scripts para gerenciar seus recursos, você pode usar a chamada de API [https://docs.aws.amazon.com/organizations/latest/APIReference/API_DescribeEffectivePolicy.html](https://docs.aws.amazon.com/organizations/latest/APIReference/API_DescribeEffectivePolicy.html). # Implementar e aplicar a marcação Nesta seção, apresentaremos as ferramentas disponíveis para as seguintes estratégias de gerenciamento de recursos: manual, infraestrutura como código (IaC) e integration/continuous entrega contínua (CI/CD). A principal dimensão dessas abordagens é uma taxa de implantação cada vez mais frequente. ## Recursos gerenciados manualmente Normalmente, essas workloads se enquadram nos [estágios básicos ou de migração da adoção](https://docs.aws.amazon.com/prescriptive-guidance/latest/migration-program-implementation/reviewing-frameworks.html). Geralmente, essas são cargas de trabalho simples, em grande parte estáticas, que foram criadas usando procedimentos escritos tradicionais ou migradas *como* estão usando ferramentas, como AWS Application Migration Service de um ambiente local. Ferramentas de migração, como o Migration Hub e o Application Migration Service, podem aplicar tags como parte do processo de migração. No entanto, se as tags não foram aplicadas durante a migração original ou o esquema de marcação mudou desde então, o [Editor de tags](https://docs.aws.amazon.com/ARG/latest/userguide/tag-editor.html) (um recurso do Console de gerenciamento da AWS) permite pesquisar recursos usando uma variedade de critérios de pesquisa e adicionar, modificar ou excluir tags em massa. Os critérios de pesquisa podem incluir recursos com ou sem a presença de uma tag ou valor específico. A API AWS Resource Tagging permite que você execute essas funções programaticamente. À medida que essas workloads são modernizadas, tipos de recursos, como grupos do Auto Scaling, são introduzidos. Esses tipos de recurso permitem maior elasticidade e maior resiliência. O grupo do Auto Scaling gerencia as instâncias do Amazon EC2 em seu nome, no entanto, você ainda pode querer que as instâncias do EC2 sejam marcadas de forma consistente com os recursos criados manualmente. Um [https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-launch-templates.html](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-launch-templates.html) fornece os meios para especificar as tags que o Auto Scaling deve aplicar às instâncias que ele cria. Quando os recursos de uma workload estão sendo gerenciados manualmente, pode ser útil automatizar a marcação de recursos. Há várias soluções disponíveis. Uma abordagem é usar Regras do AWS Config, que pode verificar `required_tags` e iniciar uma função Lambda para aplicá-las. Regras do AWS Config será descrito com mais detalhes posteriormente neste whitepaper. ## Recursos gerenciados de infraestrutura como código (IaC) AWS CloudFormation fornece uma linguagem comum para provisionar todos os recursos de infraestrutura em seu AWS ambiente. CloudFormation modelos são arquivos JSON ou YAML que criam AWS recursos de forma automatizada. Ao criar AWS recursos usando CloudFormation modelos, você pode usar a propriedade CloudFormation Resource Tags para aplicar tags aos tipos de recursos compatíveis após a criação. Gerenciar as tags e os recursos com o IaC ajuda a garantir a consistência. Quando os recursos são criados por AWS CloudFormation, o serviço aplica automaticamente um conjunto de tags AWS definidas aos recursos criados pelo AWS CloudFormation modelo. Eles são: ``` aws:cloudformation:stack-name aws:cloudformation:stack-id aws:cloudformation:logical-id ``` Você pode definir facilmente um grupo de recursos com base na AWS CloudFormation pilha. Essas tags da AWS definidas são herdadas pelos recursos criados pela pilha. No entanto, para instâncias do Amazon EC2 dentro de um grupo de Auto Scaling, [`AWS::AutoScaling::AutoScalingGroup` TagProperty](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-as-tags.html)as necessidades devem ser definidas na definição do grupo Auto Scaling em seu modelo. AWS CloudFormation Como alternativa, se você estiver usando um [modelo de inicialização do EC2](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-ec2-launchtemplate.html) com o grupo do Auto Scaling, poderá definir as tags em sua definição. É recomendável usar [modelos de inicialização do EC2](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-ec2-launchtemplate.html) com grupos de Auto Scaling ou com AWS um serviço de contêiner. Esses serviços podem ajudar a garantir a marcação consistente de suas instâncias do Amazon EC2 e também oferecer suporte ao [Auto Scaling em vários tipos de instância e opções de compra](https://aws.amazon.com/blogs/aws/new-ec2-auto-scaling-groups-with-multiple-instance-types-purchase-options/), o que pode melhorar a resiliência e otimizar seus custos computacionais. AWS CloudFormation Os [ganchos](https://aws.amazon.com/blogs/mt/proactively-keep-resources-secure-and-compliant-with-aws-cloudformation-hooks/) fornecem aos desenvolvedores um meio de manter os principais aspectos de seus aplicativos consistentes com os padrões da organização. Os hooks podem ser configurados para fornecer um *aviso* ou *impedir a implantação*. Esse recurso é mais adequado para verificar os principais elementos de configuração em seus modelos, como se um grupo do Auto Scaling está configurado para aplicar tags definidas pelo cliente a todas as instâncias do Amazon EC2 que ele executa ou para garantir que todos os buckets do Amazon S3 sejam criados com as configurações de criptografia necessárias. Em ambos os casos, a avaliação dessa conformidade está sendo adiada para o início do processo de implantação com AWS CloudFormation ganchos antes da implantação. AWS CloudFormation fornece a capacidade de detectar quando um recurso (consulte [Recursos que oferecem suporte à detecção de desvios](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/resource-import-supported-resources.html)) provisionado a partir de um modelo foi modificado e os recursos não correspondem mais às configurações de modelo esperadas. Isso é conhecido como *deriva*. Se você usa a automação para aplicar tags aos recursos gerenciados via IaC, então você os está modificando, introduzindo o drift. Ao usar o IaC, atualmente é recomendável gerenciar quaisquer requisitos de marcação como parte dos modelos do IaC, implementar AWS CloudFormation ganchos e publicar conjuntos de regras do AWS CloudFormation Guard que possam ser usados pela automação. ## Recursos gerenciados do pipeline de CI/CD À medida que a maturidade de uma workload aumenta, é provável que sejam adotadas técnicas como integração contínua e implantação contínua (CI/CD). Essas técnicas ajudam a reduzir o risco de implantação, facilitando a implantação de pequenas alterações com mais frequência com o aumento da automação dos testes. Uma estratégia de observabilidade que detecta um comportamento inesperado introduzido por uma implantação pode reverter automaticamente a implantação com o mínimo impacto no usuário. Quando você chega ao estágio de implementar dezenas de vezes por dia, aplicar tags retroativamente simplesmente não é mais prático. Tudo precisa ser expresso como código ou configuração, ter controle de versão e, sempre que possível, ser testado e avaliado antes da implantação na produção. No [modelo combinado de desenvolvimento e operações (DevOps)](https://aws.amazon.com/devops/what-is-devops/), muitas das práticas abordam as considerações operacionais como código e as validam no início do ciclo de vida da implantação. O ideal é realizar essas verificações o mais cedo possível no processo (conforme mostrado com AWS CloudFormation ganchos), para ter certeza de que seu AWS CloudFormation modelo atende às suas políticas antes que elas saiam da máquina do desenvolvedor. AWS CloudFormation O [Guard 2.0](https://aws.amazon.com/blogs/mt/introducing-aws-cloudformation-guard-2-0/) fornece os meios para escrever regras preventivas de conformidade para qualquer coisa que você possa definir. CloudFormation O modelo é validado de acordo com as regras do ambiente de desenvolvimento. Claramente, esse recurso tem uma variedade de aplicações, mas neste whitepaper, veremos apenas alguns exemplos que garantiriam que ele estivesse sempre [`AWS::AutoScaling::AutoScalingGroup` TagProperty](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-as-tags.html)sendo usado. Veja a seguir um exemplo de uma regra do CloudFormation Guard: ``` let all_asgs = Resources.*[ Type == 'AWS::AutoScaling::AutoScalingGroup' ] rule tags_asg_automation_EnvironmentId when %all_asgs !empty { let required_tags = %all_asgs.Properties.Tags.*[ Key == 'example-inc:automation:EnvironmentId' ] %required_tags[*] { PropagateAtLaunch == 'true' Value IN ['Prod', 'Dev', 'Test', 'Sandbox'] <> } } rule tags_asg_costAllocation_CostCenter when %all_asgs !empty { let required_tags = %all_asgs.Properties.Tags.*[ Key == 'example-inc:cost-allocation:CostCenter' ] %required_tags[*] { PropagateAtLaunch == 'true' Value == /^123-/ <> } } ``` No exemplo de código, filtramos o modelo para todos os recursos que são do tipo `AutoScalingGroup` e, em seguida, temos duas regras: + **`tags_asg_automation_EnvironmentId`**: verifica se existe uma tag com essa chave, se ela tem um valor dentro da lista de valores permitidos e se `PropagateAtLaunch` está definido como `true`. + **`tags_asg_costAllocation_CostCenter`**: verifica se existe uma tag com essa chave, se ela tem um valor que começa com o valor de prefixo definido e se `PropagateAtLaunch` está definido como `true`. ## Aplicação Conforme descrito anteriormente, o **Resource Groups & Tag Editor** fornece os meios para identificar onde seus recursos não atendem aos requisitos de marcação definidos nas políticas OUs de tags aplicadas à organização. O acesso à ferramenta do console do **Resource Groups & Tag Editor** de dentro da conta de um membro da organização mostra as políticas que se aplicam a essa conta e os recursos dentro da conta que não atendem aos requisitos da política de tags. Se acessado a partir da conta de gerenciamento (e se **as políticas de tags** tiverem o *acesso habilitado* nos serviços em AWS Organizations), é possível visualizar a [conformidade da política de tags para todas as contas vinculadas na organização](https://docs.aws.amazon.com/ARG/latest/userguide/tag-policies-orgs-evaluating-org-wide-compliance.html). Na própria Política de Tags, você pode ativar a aplicação de tipos de recursos específicos. No exemplo de política a seguir, adicionamos a imposição de que todos os recursos dos tipos `ec2:instance` e `ec2:volume` devem estar em conformidade com a política. Há algumas limitações conhecidas, como a necessidade de haver uma tag em um recurso para que ele seja avaliado pela política de tags. Consulte [Recursos que apoiam a fiscalização com políticas de tags](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_supported-resources-enforcement.html) para obter uma lista. ### ExampleInc-Alocação de custos.json Veja a seguir um exemplo de uma política de tags em que os relatórios and/or impõem tags de alocação de custos: ``` { "tags": { "example-inc:cost-allocation:ApplicationId": { "tag_key": { "@@assign": "example-inc:cost-allocation:ApplicationId" }, "tag_value": { "@@assign": [ "DataLakeX", "RetailSiteX" ] }, "enforced_for": { "@@assign": [ "ec2:instance", "ec2:volume" ] } }, "example-inc:cost-allocation:BusinessUnitId": { "tag_key": { "@@assign": "example-inc:cost-allocation:BusinessUnitId" }, "tag_value": { "@@assign": [ "Architecture", "DevOps", "FinanceDataLakeX" ] }, "enforced_for": { "@@assign": [ "ec2:instance", "ec2:volume" ] } }, "example-inc:cost-allocation:CostCenter": { "tag_key": { "@@assign": "example-inc:cost-allocation:CostCenter" }, "tag_value": { "@@assign": [ "123-*" ] }, "enforced_for": { "@@assign": [ "ec2:instance", "ec2:volume" ] } } } } ``` **AWS Config (`required_tag`)** AWS Config é um serviço que permite avaliar, auditar e avaliar as configurações de seus AWS recursos (consulte [Tipos de recursos suportados por AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/resource-config-reference.html)). No caso da marcação, podemos usá-la para identificar recursos que não têm tags com chaves específicas, usando a regra `required_tags` (consulte [Resource types supported by required\$1tags](https://docs.aws.amazon.com/config/latest/developerguide/required-tags.html)). No exemplo anterior, podemos testar a existência da chave em todas as instâncias do Amazon EC2. Nos casos em que a chave não existir, a instância será registrada como não compatível. Este AWS CloudFormation modelo descreve uma AWS Config regra para testar a presença das chaves obrigatórias descritas na tabela, nos buckets do Amazon S3, nas instâncias do Amazon EC2 e nos volumes do Amazon EBS. ``` Resources: MandatoryTags: Type: AWS::Config::ConfigRule Properties: ConfigRuleName: ExampleIncMandatoryTags Description: These tags should be in place InputParameters: tag1Key: example-inc:cost-allocation:ApplicationId tag2Key: example-inc:cost-allocation:BusinessUnitId tag3Key: example-inc:cost-allocation:CostCenter tag4Key: example-inc:automation:EnvironmentId Scope: ComplianceResourceTypes: - "AWS::S3::Bucket" - "AWS::EC2::Instance" - "AWS::EC2::Volume" Source: Owner: AWS SourceIdentifier: REQUIRED_TAGS ``` Para ambientes em que os recursos são gerenciados manualmente, uma AWS Config regra pode ser aprimorada para adicionar automaticamente a chave de tag ausente aos recursos usando uma correção automatizada por meio de uma AWS Lambda função. Embora isso funcione bem para workloads estáticas, é progressivamente menos eficaz à medida que você começa a gerenciar seus recursos por meio de IaC e pipelines de implantação. **AWS Organizations — As políticas de controle de serviço (SCPs)** são um tipo de política organizacional que você pode usar para gerenciar permissões em sua organização. SCPsofereça controle central sobre o máximo de permissões disponíveis para todas as contas em sua organização ou unidade organizacional (OU). SCPs afetam apenas usuários e funções gerenciados por contas que fazem parte da organização. Embora não afetem os recursos diretamente, eles restringem as permissões de usuários e funções, o que inclui as permissões para marcar ações. Com relação à marcação, SCPs pode fornecer granularidade adicional para a aplicação de tags, além do que as políticas de tags podem fornecer. No exemplo a seguir, a política negará solicitações `ec2:RunInstances` quando a tag `example-inc:cost-allocation:CostCenter` não estiver presente. O seguinte é uma negação do SCP: ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "DenyRunInstanceWithNoCostCenterTag", "Effect": "Deny", "Action": "ec2:RunInstances", "Resource": [ "arn:aws:ec2:*:*:instance/*" ], "Condition": { "Null": { "aws:RequestTag/example-inc:cost-allocation:CostCenter": "true" } } } ] } ``` ------ Não é possível recuperar a política efetiva de controle de serviços que se aplica a uma conta vinculada por design. Quando você impõe a marcação SCPs, a documentação precisa estar disponível para os desenvolvedores para que eles possam garantir que seus recursos atendam às políticas que foram aplicadas às suas contas. Fornecer acesso somente de leitura aos CloudTrail eventos em sua conta pode ajudar os desenvolvedores na tarefa de depuração quando seus recursos não estão em conformidade. # Medir a eficácia da marcação e promover melhorias Depois de implementar uma estratégia de marcação, é importante medir sua eficácia em relação aos casos de uso desejados. A medida de eficácia variará de acordo com o caso de uso. Por exemplo: + **Atribuição de custos**: você pode medir a cobertura de marcação de recursos com base nos gastos usando ferramentas como o [AWS Cost Explorer](https://aws.amazon.com/aws-cost-management/aws-cost-explorer/) ou o [Relatório de Custos e Uso da AWS](https://aws.amazon.com/aws-cost-management/aws-cost-and-usage-reporting/). Por exemplo, você pode monitorar a *porcentagem de recursos marcados ou não marcados* que geram cobranças, especialmente monitorando chaves de tag específicas. + **Automação**: talvez você queira auditar se o resultado desejado foi alcançado. Por exemplo, se as instâncias não produtivas do Amazon EC2 são suspensas fora do horário comercial, auditando os horários de início e término da instância. O [Resource Groups & Tag Editor](https://docs.aws.amazon.com/ARG/latest/userguide/resource-groups.html) na conta de gerenciamento fornece recursos adicionais para analisar a conformidade com a política de tags para todas as contas vinculadas em sua organização. Com base nos resultados da medição da eficácia da marcação, identifique se são necessárias melhorias ou alterações em alguma das etapas, como definição do caso de uso, implementação ou aplicação do esquema de marcação. Faça as alterações necessárias e repita o ciclo até que a eficácia desejada seja alcançada. No exemplo com atribuição de custos, você pode observar a melhoria percentual. Como são os desenvolvedores e operadores que precisam realizar a marcação real dos recursos, é fundamental que eles assumam a responsabilidade. Essa não é a única responsabilidade adicional que as equipes normalmente assumem em sua jornada de AWS adoção. O aumento da responsabilidade pela segurança e pelo custo de desenvolvimento e operação das aplicações também é importante. As organizações costumam usar metas e metas como meio de motivar a adoção de novas práticas, então isso também pode ser aplicado aqui.