Recursos administrados manualmente Recursos administrados por la infraestructura como código (IaC)Recursos administrados por canalización de CI/CD Cumplimiento

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. 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 CloudEndure desde un entorno en las instalaciones. Las herramientas de migración, por ejemplo, Migration Hub y CloudEndure, 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 (una característica de la AWS Management Console) 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 plantilla de lanzamiento de Amazon EC2 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 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 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 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, que pueden mejorar la resiliencia y optimizar los costos informáticos.

Los enlaces de AWS CloudFormation 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 vaya a lanzar 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) 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) 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 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 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']
        <<Tag must have a permitted value
          Tag must have PropagateAtLaunch set to 'true'>>
    }
}

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-/
        <<Tag must have a permitted value
          Tag must have PropagateAtLaunch set to 'true'>>
    }
}

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.

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 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). 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_tags). 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:


{
  "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.

Aviso JavaScript está desactivado o no está disponible en su navegador.

Para utilizar la documentación de AWS, debe estar habilitado JavaScript. Para obtener más información, consulte las páginas de ayuda de su navegador.

Convenciones del documento

AWS Organizations: Políticas de etiquetas

Medir la eficacia del etiquetado e impulsar mejoras