# Creación de la estrategia de etiquetado Como ocurre con muchas prácticas de operaciones, la implementación de una estrategia de etiquetado es *un proceso de iteración y mejora*. Comience poco a poco con su prioridad inmediata y amplíe el esquema de etiquetado a medida que lo necesite. ![\[Diagrama que muestra una representación gráfica del ciclo de iteración y mejora de la estrategia de etiquetado\]](http://docs.aws.amazon.com/es_es/whitepapers/latest/tagging-best-practices/images/tagging-strategy-cycle.png) A lo largo de este proceso, la propiedad es clave para la responsabilidad y el progreso. Como las etiquetas se pueden utilizar para una variedad de propósitos, la estrategia general de etiquetado se puede dividir en áreas de responsabilidad dentro de una organización. El etiquetado permite un enfoque programático de las actividades que dependen de la caracterización de los recursos. La variedad de partes interesadas que pueden beneficiarse del etiquetado dependerá del tamaño de la organización y de las prácticas operativas. Las organizaciones más grandes pueden beneficiarse de una definición clara de las responsabilidades de los equipos que participan en la creación e implementación de una estrategia de etiquetado. Algunas partes interesadas pueden ser responsables de identificar las necesidades (definir los casos de uso) del etiquetado; otras pueden ser responsables de mantener, implementar y mejorar la estrategia de etiquetado. Al asignar la propiedad, se encuentra en una buena posición para implementar aspectos individuales de la estrategia. Cuando proceda, esta propiedad puede formalizarse como política y documentarse en una matriz de responsabilidad (por ejemplo, RACI: responsable, confiable, consultada e informada) o en un modelo de responsabilidad compartida. En las organizaciones más pequeñas, es posible que los equipos desempeñen múltiples funciones en una estrategia de etiquetado, desde la definición de los requisitos hasta la implementación y el cumplimiento. # Definición de las necesidades y los casos de uso Comience a desarrollar la estrategia interactuando con las partes interesadas que tienen una necesidad subyacente fundamental de consumir metadatos. Estos equipos definen los metadatos con los que deben etiquetarse los recursos para respaldar las actividades, como la elaboración de informes, la automatización y la clasificación de datos. Describen cómo deben organizarse los recursos y a qué políticas se deben asignar. Algunos ejemplos de roles y funciones que estas partes interesadas pueden tener en las organizaciones: + **Finanzas** y **Línea de negocio** deben comprender el valor de la inversión asignándolo a los costos para priorizar las acciones que deben tomarse al abordar la ineficiencia. La comprensión del *costo frente al valor generado* ayuda a identificar las líneas de negocio o las ofertas de productos erróneas. Esto lleva a tomar decisiones informadas sobre la continuidad del soporte, la adopción de una alternativa (por ejemplo, el uso de una oferta de SaaS o un servicio administrado) o la retirada de una oferta empresarial no rentable. + La **gobernanza** y el **cumplimiento** deben comprender la categorización de los datos (por ejemplo, públicos o confidenciales), si una carga de trabajo específica está dentro o fuera del ámbito de auditoría según una norma o reglamento específicos y la importancia del servicio (si el servicio o la aplicación son fundamentales para la empresa) para aplicar los controles y la supervisión adecuados, como los permisos, las políticas y el monitoreo. + Las **operaciones** y el **desarrollo** necesitan comprender el ciclo de vida de la carga de trabajo, las etapas de implementación de los productos compatibles y la gestión de las etapas de lanzamiento (por ejemplo, desarrollo, prueba o división de producción), así como las prioridades de soporte asociadas y los requisitos de gestión de las partes interesadas. También es necesario definir y comprender tareas como las copias de seguridad, la aplicación de parches, la observabilidad y la obsolescencia. + **Seguridad de la información (InfoSec)** y **Operaciones de seguridad (SecOps)** describen qué controles se deben aplicar y cuáles se recomiendan. InfoSec normalmente define la implementación de los controles y SecOps generalmente es responsable de administrarlos. En función del caso de uso, las prioridades, el tamaño de la organización y las prácticas operativas, es posible que necesite la representación de varios equipos de la organización, como los de finanzas (incluidas las adquisiciones), seguridad de la información, habilitación de la nube y operaciones en la nube. También necesita la representación de los propietarios de aplicaciones y procesos para funciones como la aplicación de parches, la copia de seguridad y la restauración, el monitoreo, la programación de tareas y la recuperación de desastres. Estos representantes ayudan a impulsar la definición, la implementación y la medición de la eficacia de la estrategia de etiquetado. Deberían [https://www.youtube.com/watch?v=aFdpBqmDpzM](https://www.youtube.com/watch?v=aFdpBqmDpzM) a partir de las partes interesadas y los casos de uso y llevar a cabo un taller interfuncional. En el taller, tienen la oportunidad de compartir sus perspectivas y necesidades y ayudar a impulsar una estrategia general. Más adelante en este documento técnico se describen ejemplos de los participantes y su participación en varios casos de uso. Las partes interesadas también definen y validan las claves de las etiquetas obligatorias y pueden recomendar el alcance de las etiquetas opcionales. Por ejemplo, es posible que los equipos financieros necesiten relacionar un recurso con un centro de costos interno, una unidad empresarial o ambos. Por lo tanto, es posible que necesiten que determinadas claves de etiquetas, como `CostCenter` y `BusinessUnit`, sean obligatorias. Es posible que los equipos de desarrollo individuales decidan utilizar etiquetas adicionales con fines de automatización, como `EnvironmentName`, `OptIn` u `OptOut`. Las principales partes interesadas deben ponerse de acuerdo sobre el enfoque de la estrategia de etiquetado y documentar las respuestas a las preguntas relacionadas con el cumplimiento y el gobierno, tales como: + ¿Qué casos de uso se deben abordar? + ¿Quién es responsable de etiquetar los recursos (implementación)? + ¿Cómo se aplican las etiquetas y qué métodos y automatizaciones se utilizarán (proactivos o reactivos)? + ¿Cómo se miden la eficacia y los objetivos del etiquetado? + ¿Con qué frecuencia se debe revisar la estrategia de etiquetado? + ¿Quién impulsa las mejoras? ¿Cómo se hace esto? Las funciones empresariales, como la habilitación de la nube, la gestión empresarial de la nube y la ingeniería de plataformas de la nube, pueden entonces desempeñar un papel de facilitadoras para el proceso de creación de la estrategia de etiquetado, ayudar a impulsar su adopción y garantizar la coherencia de su aplicación al medir el progreso, eliminar los obstáculos y reducir la duplicación de esfuerzos. # Definición y publicación de un esquema de etiquetado Emplee un enfoque coherente al etiquetar los recursos de AWS, tanto para etiquetas obligatorias como opcionales. Un esquema de etiquetado completo le ayuda a lograr esta coherencia. Los siguientes ejemplos le pueden ayudar a comenzar: + Acordar las claves de etiquetas obligatorias + Definir los valores aceptables y las convenciones de nomenclatura de las etiquetas (mayúsculas o minúsculas, guiones o guiones bajos, jerarquía, etc.) + Confirmar valores no constituiría información de identificación personal (PII) + Decidir quién puede definir y crear nuevas claves de etiquetas + Acordar cómo agregar nuevos valores de etiquetas obligatorios y cómo administrar las etiquetas opcionales Revise la tabla [categorías de etiquetado](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html) siguiente, que se puede utilizar como referencia de lo que es posible que incluya en el esquema de etiquetado. Aún debe determinar la convención que utilizará para la clave de etiqueta y los valores permitidos para cada una de ellas. El esquema de etiquetado es el documento en el que se define esto para el entorno. *Tabla 6: Ejemplo de un esquema de etiquetado definitivo* | Caso de uso | Clave de etiqueta | Justificación | Valores permitidos (mostrados o con el prefijo o sufijo del valor) | Usado para la asignación de costos | Tipos de recursos | Ámbito | Obligatorio | | --- | --- | --- | --- | --- | --- | --- | --- | | Asignación de costos | example-inc:cost-allocation:ApplicationId | Realizar un seguimiento del costo frente al valor generado por cada línea de negocio | DataLakeX, RetailSiteX | S | Todos | Todos | Obligatorio | | Asignación de costos | example-inc:cost-allocation:BusinessUnitId | Monitorear los costos por unidad de negocio | Architecture, DevOps, Finance | S | Todos | Todos | Obligatorio | | Asignación de costos | example-inc:cost-allocation:CostCenter | Monitorear los costos por centro de costos | 123-\$1 | S | Todos | Todos | Obligatorio | | Asignación de costos | example-inc:cost-allocation:Owner | Qué titular del presupuesto es responsable de esta carga de trabajo | Marketing, RetailSupport | S | Todos | Todos | Obligatorio | | Control de acceso | example-inc:access-control:LayerId | Identificar el subcomponente o la capa para conceder el acceso a los recursos en función del rol | DB\$1Layer, Web\$1Layer, App\$1Layer | N | Todos | Todos | Opcional | | Automatización | example-inc:automation:EnvironmentId | Implementar la programación de los entornos de prueba y desarrollo, también denominada fase del ciclo de vida del desarrollo del software (SDLC) | Prod, Dev, Test, Sandbox | N | EC2, RDS, EBS | Todos | Obligatorio | | DevOps | example-inc:operations:Owner | Qué equipo o plantilla es responsable de la creación y el mantenimiento del recurso | Squad01 | N | Todos | Todos | Obligatorio | | Recuperación ante desastres | example-inc:disaster-recovery:rpo | Definir el objetivo de punto de recuperación (RPO) de un recurso | 6h, 24h | N | S3, EBS | Prod. | Obligatorio | | Clasificación de datos | example-inc:data:classification | Clasificar los datos para garantizar el cumplimiento y el gobierno | Public, Private, Confidential, Restricted | N | S3, EBS | Todos | Obligatorio | | Conformidad | example-inc:compliance:framework | Identifica el marco de cumplimiento al que está sujeta la carga de trabajo | PCI-DSS, HIPAA | N | Todos | Prod. | Obligatorio | Una vez definido el esquema de etiquetado, administre el esquema en un repositorio con control de versiones al que puedan acceder todas las partes interesadas pertinentes para facilitar su consulta y realizar un seguimiento de las actualizaciones. Este enfoque mejora la eficiencia y permite la agilidad. # AWS Organizations: Políticas de etiquetas Las políticas de AWS Organizations le permiten aplicar tipos adicionales de administración a las Cuentas de AWS de la organización. Una [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) es la forma en que puede expresar el esquema de etiquetado en formato JSON para que la plataforma pueda informar y, opcionalmente, aplicar el esquema en el entorno de AWS. La política de etiquetas define los valores que son aceptables para una clave de etiqueta en tipos de recursos específicos. Esta política puede tener la forma de una lista de valores o de un prefijo seguido de un carácter comodín (`*`). El enfoque de prefijo simple es menos riguroso que una lista discreta de valores, pero requiere menos mantenimiento. Los siguientes ejemplos muestran cómo definir una política de etiquetado para validar los valores que son aceptables para una clave determinada. Partiendo de la definición tabular del esquema sencilla, puede transcribir esta información en una o más políticas de etiquetas. Se pueden usar políticas independientes para respaldar la propiedad delegada o es posible que algunas políticas solo se apliquen en escenarios específicos. ## ExampleInc-CostAllocation.json A continuación, se muestra un ejemplo de una política de etiquetas que informa sobre las etiquetas de asignación de costos: ``` { "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 A continuación, se muestra un ejemplo de una política de etiquetas que informa sobre las etiquetas de recuperación de desastres: ``` { "tags": { "example-inc:disaster-recovery:rpo": { "tag_key": { "@@assign": "example-inc:disaster-recovery:rpo" }, "tag_value": { "@@assign": [ "6h", "24h" ] } } } } ``` En este ejemplo, la política de etiquetas `ExampleInc-CostAllocation` se adjunta a la unidad organizativa `Workloads` y, por lo tanto, se aplica a todas las cuentas de las unidades organizativas secundarias `Prod` y `Test`. Del mismo modo, la política de etiquetas `ExampleInc-DisasterRecovery` se adjunta a la unidad organizativa `Prod` y, por lo tanto, solo se aplica a las cuentas por debajo de esta unidad organizativa. El documento técnico [Organización del entorno mediante varias cuentas](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/organizing-your-aws-environment.html) analiza con más detalle las estructuras de las unidades organizativas recomendadas. ![\[Diagrama que muestra la vinculación de las políticas de etiquetas a una estructura de unidad organizativa y la política efectiva\]](http://docs.aws.amazon.com/es_es/whitepapers/latest/tagging-best-practices/images/adding-tagging-to-policies-in-ou-structure.png) Al examinar la cuenta de `marketing-prod` en el diagrama, ambas políticas de etiquetas se aplican a esta cuenta, por lo que tenemos el concepto de una *política efectiva*, que es la convolución de las políticas de un tipo determinado que se aplican a una cuenta. Si administra los recursos principalmente de forma manual, puede revisar la política vigente consultando [Grupos de recursos y editor de etiquetas: políticas de etiquetas](https://console.aws.amazon.com/resource-groups/tag-policies) en la consola. Si utiliza la infraestructura como código (IaC) o secuencias de comandos para administrar los recursos, puede utilizar la llamada a la API [https://docs.aws.amazon.com/organizations/latest/APIReference/API_DescribeEffectivePolicy.html](https://docs.aws.amazon.com/organizations/latest/APIReference/API_DescribeEffectivePolicy.html). # Implementación y aplicación del etiquetado En esta sección, le presentaremos las herramientas disponibles para las siguientes estrategias de administración de recursos: manual, infraestructura como código (IaC) e integración continua o entrega continua (CI/CD). La dimensión clave de estos enfoques es una tasa de implementación cada vez más frecuente. ## Recursos administrados manualmente Por lo general, se trata de cargas de trabajo que se encuentran en las [etapas básicas o de migración de la adopción](https://docs.aws.amazon.com/prescriptive-guidance/latest/migration-program-implementation/reviewing-frameworks.html). A menudo, se trata de cargas de trabajo simples, en gran parte estáticas, que se han creado mediante procedimientos escritos tradicionales o que se han migrado *junto* con herramientas como AWS Application Migration Service desde un entorno en las instalaciones. Las herramientas de migración, por ejemplo, Migration Hub y Application Migration Service, pueden aplicar etiquetas como parte del proceso de migración. Sin embargo, si las etiquetas no se aplicaron durante la migración original o si el esquema de etiquetado ha cambiado desde entonces, el [Editor de etiquetas](https://docs.aws.amazon.com/ARG/latest/userguide/tag-editor.html) (una característica de la Consola de administración de AWS) le permite buscar recursos mediante diversos criterios de búsqueda y agregar, modificar o eliminar etiquetas de forma masiva. Los criterios de búsqueda pueden incluir recursos con o sin la presencia de una etiqueta o valor en particular. La API de etiquetado de recursos de AWS le permite realizar estas funciones mediante programación. A medida que se modernizan estas cargas de trabajo, se ingresan tipos de recursos, como los grupos de escalado automático. Estos tipos de recursos permiten una mayor elasticidad y una mejor resiliencia. El grupo de escalado automático administra las instancias de Amazon EC2 en su nombre; sin embargo, es posible que desee etiquetar las instancias EC2 de forma coherente con los recursos creados manualmente. Una [https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-launch-templates.html](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-launch-templates.html) proporciona los medios para especificar las etiquetas que el escalado automático debe aplicar a las instancias que crea. Cuando los recursos de una carga de trabajo se administran manualmente, puede resultar útil automatizar el etiquetado de los recursos. Hay varias soluciones disponibles. Un enfoque consiste en utilizar Reglas de AWS Config, que puede comprobar `required_tags` y, a continuación, iniciar una función de Lambda para aplicarlas. Reglas de AWS Config se describe con más detalle más adelante en este documento técnico. ## Recursos administrados por la infraestructura como código (IaC) AWS CloudFormation proporciona un lenguaje común para aprovisionar todos los recursos de infraestructura del entorno de AWS. Las plantillas de CloudFormation son archivos JSON o YAML que crean recursos de AWS de forma automatizada. Cuando crea recursos de AWS que utilizan plantillas de CloudFormation, puede utilizar la propiedad Etiquetas de recursos de CloudFormation para aplicar etiquetas a los tipos de recursos compatibles al crearlos. Administrar las etiquetas y los recursos con IaC ayuda a garantizar la coherencia. Cuando AWS CloudFormation crea los recursos, el servicio aplica automáticamente un conjunto de etiquetas definidas por AWS a los recursos creados por la plantilla de AWS CloudFormation. Estos son: ``` aws:cloudformation:stack-name aws:cloudformation:stack-id aws:cloudformation:logical-id ``` Puede definir fácilmente un grupo de recursos en función de la pila de AWS CloudFormation. Estas etiquetas definidas por AWS las heredan los recursos creados por la pila. Sin embargo, para las instancias de Amazon EC2 dentro de un grupo de escalado automático, [`AWS::AutoScaling::AutoScalingGroup` TagProperty](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-as-tags.html) se debe establecer en la definición del grupo de escalado automático de la plantilla de AWS CloudFormation. Alternativamente, si utiliza una [Plantilla de lanzamiento de EC2](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-ec2-launchtemplate.html) con el grupo de escalado automático, puede definir las etiquetas en su definición. Se recomienda el uso de [plantillas de lanzamiento de EC2](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-ec2-launchtemplate.html) con grupos de escalado automático o con un servicio de contenedores de AWS. Estos servicios pueden ayudar a garantizar un etiquetado coherente de las instancias de Amazon EC2 y también son compatibles con el [escalado automático entre varios tipos de instancias y opciones de compra](https://aws.amazon.com/blogs/aws/new-ec2-auto-scaling-groups-with-multiple-instance-types-purchase-options/), que pueden mejorar la resiliencia y optimizar los costos informáticos. Los [enlaces de AWS CloudFormation](https://aws.amazon.com/blogs/mt/proactively-keep-resources-secure-and-compliant-with-aws-cloudformation-hooks/) proporcionan a los desarrolladores un medio para mantener la coherencia de los aspectos clave de la aplicación con los estándares de la organización. Los enlaces se pueden configurar para proporcionar un *aviso* o *impedir la implementación*. Esta característica es la más adecuada para comprobar los elementos de configuración clave de las plantillas, por ejemplo, si un grupo de escalado automático está configurado para aplicar etiquetas definidas por el cliente a todas las instancias de Amazon EC2 que lanza o para garantizar que todos los buckets de Amazon S3 se creen con la configuración de cifrado requerida. En ambos casos, la evaluación de este cumplimiento se está aplazando hasta una fase temprana del proceso de implementación con enlaces de AWS CloudFormation antes de la implementación. AWS CloudFormation proporciona la capacidad de detectar cuándo un recurso (consulte [Recursos que respaldan la detección de desviaciones](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/resource-import-supported-resources.html)) aprovisionado a partir de una plantilla se ha modificado y los recursos ya no coinciden con las configuraciones de plantilla esperadas. Esto se conoce como *desviación*. Si utiliza la automatización para aplicar etiquetas a los recursos administrados a través de IaC, los está modificando e ingresando una desviación. Al utilizar IaC, actualmente se recomienda administrar cualquier requisito de etiquetado como parte de las plantillas de IaC, implementar los enlaces de AWS CloudFormation y publicar los conjuntos de reglas de AWS CloudFormation Guard que puede utilizar la automatización. ## Recursos administrados por canalización de CI/CD A medida que aumenta la madurez de una carga de trabajo, es probable que se adopten técnicas como la integración y la implementación continuas (CI/CD). Estas técnicas ayudan a reducir el riesgo de implementación al facilitar la implementación de pequeños cambios con mayor frecuencia y, al mismo tiempo, aumentar la automatización de las pruebas. Una estrategia de observabilidad que detecta un comportamiento inesperado ingresado por una implementación puede revertirla automáticamente con un impacto mínimo en los usuarios. Al llegar a la fase de implementación decenas de veces al día, aplicar etiquetas retroactivamente ya no es práctico. Todo se debe expresar como código o configuración, controlar las versiones y, siempre que sea posible, probarse y evaluarse antes de implementarlo en producción. En el [modelo de desarrollo y operaciones (DevOps)](https://aws.amazon.com/devops/what-is-devops/) combinado, muchas de las prácticas abordan las consideraciones operativas en forma de código y las validan al principio del ciclo de vida de la implementación. Lo ideal sería realizar estas comprobaciones lo antes posible en el proceso (como se muestra con los enlaces de AWS CloudFormation), para que pueda estar seguro de que la plantilla de AWS CloudFormation cumple con las políticas antes de que salga de la máquina para desarrolladores. [AWS CloudFormation Guard 2.0](https://aws.amazon.com/blogs/mt/introducing-aws-cloudformation-guard-2-0/) proporciona los medios para redactar reglas de cumplimiento preventivo para todo lo que pueda definir con CloudFormation. La plantilla se valida según las reglas del entorno de desarrollo. Evidentemente, esta característica tiene una amplia gama de aplicaciones, pero en este documento técnico solo veremos algunos ejemplos que garantizarían que [`AWS::AutoScaling::AutoScalingGroup` TagProperty](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-as-tags.html) se utilice siempre. A continuación, se muestra un ejemplo de una regla de 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-/ <> } } ``` En el ejemplo de código, filtramos la plantilla para todos los recursos que son del tipo `AutoScalingGroup` y, a continuación, tenemos dos reglas: + **`tags_asg_automation_EnvironmentId`**: comprueba que existe una etiqueta con esta clave, que tiene un valor dentro de la lista de valores permitidos y que `PropagateAtLaunch` se establece en `true` + **`tags_asg_costAllocation_CostCenter`**: comprueba que existe una etiqueta con esta clave, que tiene un valor que comienza con el valor de prefijo definido y que `PropagateAtLaunch` se establece en `true` ## Cumplimiento Como se ha descrito anteriormente, el **editor de grupos de recursos y etiquetas** proporciona los medios para identificar los casos en los que los recursos no cumplen con los requisitos de etiquetado definidos en las políticas de etiquetado que se aplican a las unidades organizativas de la organización. Al acceder a la herramienta de la consola **editor de grupos de recursos y etiquetas** desde la cuenta de un miembro de la organización, se muestran las políticas que se aplican a esa cuenta y el recurso de la cuenta que no cumple los requisitos de la política de etiquetas. Si se accede desde la cuenta de administración (y si **Políticas de etiquetas** tiene el *Acceso habilitado* en los servicios de AWS Organizations), entonces es posible ver el [cumplimiento de la política de etiquetas para todas las cuentas vinculadas de la organización](https://docs.aws.amazon.com/ARG/latest/userguide/tag-policies-orgs-evaluating-org-wide-compliance.html). Dentro de la propia Política de etiquetas, puede habilitar la aplicación para tipos de recursos específicos. En el siguiente ejemplo de política, hemos agregado la aplicación de manera que todos los tipos de recursos `ec2:instance` y `ec2:volume` deben cumplir con la política. Existen algunas limitaciones conocidas, como que debe haber una etiqueta en un recurso para que la política de etiquetas la evalúe. Consulte [Recursos que respaldan la aplicación con políticas de etiquetas](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_supported-resources-enforcement.html) para obtener una lista. ### ExampleInc-Cost-Allocation.json A continuación, se muestra un ejemplo de una política de etiquetas que informa o aplica las etiquetas de asignación de costos: ``` { "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 es un servicio que le permite evaluar y auditar las configuraciones de los recursos de AWS (consulte [Tipos de recursos compatibles con AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/resource-config-reference.html)). En el caso del etiquetado, podemos usarlo para identificar los recursos que carecen de etiquetas con claves específicas, con la regla `required_tags` (consulte [Tipos de recursos compatibles con required\$1tags](https://docs.aws.amazon.com/config/latest/developerguide/required-tags.html)). En el ejemplo anterior, podríamos comprobar la existencia de la clave en todas las instancias de Amazon EC2. En los casos en los que la clave no exista, la instancia se registrará como no compatible. Esta plantilla de AWS CloudFormation describe una regla de AWS Config para comprobar la presencia de las claves obligatorias descritas en la tabla, en los buckets de Amazon S3, las instancias de Amazon EC2 y los volúmenes de 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 los entornos en los que los recursos se administran manualmente, una regla de AWS Config se puede mejorar para agregar automáticamente la clave de etiqueta que falta a los recursos mediante una corrección automática a través de una función de AWS Lambda. Aunque esto funciona bien para las cargas de trabajo estáticas, es cada vez menos eficaz a medida que se empiezan a administrar los recursos mediante IaC y canalizaciones de implementación. **AWS Organizations: las políticas de control de servicio (SCP)** son un tipo de política de organización que puede utilizar para administrar permisos en la organización. Las políticas de control de servicios (SCP) ofrecen un control central sobre los máximos permisos disponibles para todas las cuentas de la organización o unidad organizativa (OU). Las SCP solo afectan a los usuarios y roles administrados por cuentas que forman parte de la organización. Aunque no afectan directamente a los recursos, restringen los permisos de los usuarios y los roles, lo que incluye los permisos para etiquetar las acciones. Con respecto al etiquetado, las SCP pueden proporcionar detalles adicionales a la hora de aplicar el etiquetado, además de lo que pueden ofrecer las políticas de etiquetado. En el siguiente ejemplo, la política denegará solicitudes `ec2:RunInstances` donde la etiqueta `example-inc:cost-allocation:CostCenter` no está presente. A continuación, se muestra una SCP de denegación: ------ #### [ 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" } } } ] } ``` ------ Por diseño, no es posible recuperar la política de control de servicios efectiva que se aplica a una cuenta enlazada. Cuando se impone el etiquetado con las SCP, la documentación debe estar disponible para que los desarrolladores puedan garantizar que los recursos cumplen con las políticas que se han aplicado a las cuentas. Proporcionar acceso de solo lectura a los eventos de CloudTrail de la cuenta puede ayudar a los desarrolladores a realizar tareas de depuración cuando los recursos no cumplen con los requisitos. # Medir la eficacia del etiquetado e impulsar mejoras Una vez implementada una estrategia de etiquetado, es importante medir su eficacia en función de los casos de uso objetivo. La medida de la eficacia variará según el caso de uso. Por ejemplo: + **Atribución de costos**: puede medir la cobertura de etiquetado de los recursos en función del gasto con herramientas como [AWS Cost Explorer](https://aws.amazon.com/aws-cost-management/aws-cost-explorer/) o [informe de costo y uso de AWS](https://aws.amazon.com/aws-cost-management/aws-cost-and-usage-reporting/). Por ejemplo, podría realizar un seguimiento del *porcentaje de recursos etiquetados o no etiquetados* que generan cargos, en particular el monitoreo de claves de etiquetas específicas. + **Automatización**: es posible que desee auditar si se ha logrado el resultado deseado. Por ejemplo, si las instancias de Amazon EC2 que no están en producción se suspenden fuera del horario laboral o auditar las horas de inicio y finalización de las instancias. [Editor de grupos de recursos y etiquetas](https://docs.aws.amazon.com/ARG/latest/userguide/resource-groups.html) dentro de la cuenta de administración, ofrece funciones adicionales para analizar el cumplimiento de la política de etiquetas en todas las cuentas enlazadas de la organización. En función de los resultados de la medición de la eficacia del etiquetado, identifique si es necesaria alguna mejora o modificación en alguno de los pasos, como la definición de los casos de uso, la implementación o el cumplimiento del esquema de etiquetado. Realice los cambios necesarios y repita el ciclo hasta lograr la eficacia deseada. En el ejemplo de la atribución de costos, puede ver el porcentaje de mejora. Dado que son los desarrolladores y los operadores los que tienen que etiquetar los recursos propiamente dichos, es fundamental que se hagan cargo de ellos. Esta no es la única responsabilidad adicional que suelen asumir los equipos a lo largo de su trayectoria de adopción de AWS. También es importante aumentar la responsabilidad por la seguridad y el costo de desarrollar la aplicación y su funcionamiento. Las organizaciones suelen utilizar los objetivos y metas como medio para motivar la adopción de nuevas prácticas, por lo que esto también se puede aplicar en este caso.