# Etiquetado de casos de uso **Topics** + [Etiquetas para la asignación de costos y la administración financiera](tags-for-cost-allocation-and-financial-management.md) + [Etiquetas para operaciones y ayuda](tags-for-operations-and-support.md) + [Etiquetas para la seguridad de los datos, la administración de riesgos y el control de acceso](tags-for-data-security-risk-management-and-access-control.md) # Etiquetas para la asignación de costos y la administración financiera Uno de los primeros casos de uso del etiquetado que suelen abordar las organizaciones es la visibilidad y la administración de los costos y el uso. Por lo general, esto se debe a varios motivos: + **Normalmente, es un escenario bien entendido y los requisitos son bien conocidos.** Por ejemplo, los equipos financieros desean ver el costo total de las cargas de trabajo y la infraestructura que abarcan varios servicios, características, cuentas o equipos. Una forma de lograr esta visibilidad de los costos es mediante un etiquetado coherente de los recursos. + **Las etiquetas y sus valores están claramente definidos.** Por lo general, los mecanismos de asignación de costos ya existen en los sistemas financieros de una organización, por ejemplo, el seguimiento por centro de costos, unidad de negocio, equipo o función de la organización. + **Retorno de la inversión rápido y demostrable.** Es posible realizar un seguimiento de las tendencias de optimización de costos a lo largo del tiempo si los recursos se etiquetan de forma coherente, por ejemplo, si los recursos tienen el tamaño correcto, se escalan automáticamente o se programan. Entender cómo se incurre en los costos en AWS le permite tomar decisiones financieras informadas. Saber dónde se han generado costos a nivel de recursos, carga de trabajo, equipo u organización mejora la comprensión del valor ofrecido en el nivel correspondiente en comparación con los resultados empresariales logrados. Es posible que los equipos de ingeniería no tengan experiencia en la administración financiera de los recursos. Adjuntar a una persona con una destreza especializada en administración financiera de AWS que pueda entrenar a los equipos de ingeniería y desarrollo sobre los conceptos básicos de la administración financiera de AWS y la creación de una relación entre las finanzas y la ingeniería para fomentar la cultura de FinOps ayudará a lograr resultados mensurables para la empresa y alentarán a los equipos a construir teniendo en cuenta los costos. El establecimiento de prácticas financieras recomendadas se analiza en profundidad en [Pilar de optimización de costos](https://docs.aws.amazon.com/wellarchitected/latest/cost-optimization-pillar/welcome.html) del Marco de Buena Arquitectura, pero abordaremos algunos de los principios fundamentales en este documento técnico. # Etiquetas de asignación de costos La asignación de costos se refiere a la asignación o distribución de los costos generados a los usuarios o beneficiarios de esos costos siguiendo un proceso definido. En el contexto de este documento técnico, dividimos la asignación de costos en dos tipos: *análisis* y *reintegro*. Las herramientas y los mecanismos de *análisis* ayudan a aumentar el conocimiento de los costos. El *reintegro* contribuye a la recuperación de los costos e impulsa el conocimiento de los costos. El *análisis* trata de la presentación, el cálculo y los informes de los cargos que ha generado una entidad específica, como una unidad de negocio, una aplicación, un usuario o un centro de costos. Por ejemplo: “El equipo de ingeniería de infraestructuras fue responsable de una inversión de X \$1 de AWS el mes pasado”. El *reintegro* se refiere al cargo real de los costos generados a esas entidades a través de los procesos contables internos de una organización, como los sistemas financieros o los comprobantes diarios. Por ejemplo: “Se dedujeron X \$1 del presupuesto de AWS para el equipo de ingeniería de infraestructuras”. En ambos casos, el etiquetado de los recursos adecuadamente puede ayudar a asignar el costo a una entidad, con la única diferencia de si se espera que alguien realice un pago o no. Es posible que el gobierno financiero de la organización requiera una contabilidad transparente de los costos generados a nivel de aplicación, unidad de negocio, centro de costos y equipo. Realizar la atribución de costos con el apoyo de las [Etiquetas de asignación de costos](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/cost-alloc-tags.html) le proporciona los datos necesarios para atribuir con precisión los costos generados por una entidad a partir de los recursos debidamente etiquetados. + **Responsabilidad**: asegúrese de que el costo se asigne a quienes son responsables del uso de los recursos. Un único punto de servicio o grupo puede ser responsable de la revisión y la elaboración de informes sobre los gastos. + **Transparencia financiera**: muestre una visión clara de las asignaciones en efectivo a TI mediante la creación de paneles eficaces y un análisis de costos significativo para el liderazgo. + **Inversiones informadas de TI**: realice un seguimiento del ROI en función del proyecto, la aplicación o la línea de negocio y permita a los equipos tomar mejores decisiones empresariales, por ejemplo, destinando más fondos a las aplicaciones que generan ingresos. En resumen, las etiquetas de asignación de costos pueden ayudarle a saber: + ¿Quién es el propietario del gasto y quién es responsable de optimizarlo? + ¿En qué carga de trabajo, aplicación o producto se está gastando? ¿Qué entorno o etapa? + ¿Qué áreas de gasto están creciendo más rápido? + ¿Cuánto gasto se puede deducir de un presupuesto de AWS basado en tendencias del pasado? + ¿Cuál fue el impacto de los esfuerzos de optimización de costos en determinadas cargas de trabajo, aplicaciones o productos? La activación de las etiquetas de recursos para la asignación de costos ayuda a definir prácticas de medición dentro de la organización que se pueden utilizar para proporcionar visibilidad de uso de AWS que aumenta la transparencia en la rendición de cuentas por el gasto. También se centra en crear un nivel adecuado de detalle con respecto a la visibilidad de los costos y el uso, y en influir en los comportamientos de consumo de la nube mediante la elaboración de informes de asignación de costos y el seguimiento de los KPI. # Elaboración de una estrategia de asignación de costos ## Definición e implementación de un modelo de asignación de costos Cree una estructura de cuenta y de costos para los recursos que se van a implementar en AWS. Establezca la relación entre los costos de gasto de AWS, cómo se generaron esos costos y quién o qué generó esos costos. Las estructuras de costos comunes se basan en AWS Organizations, Cuentas de AWS, entornos y entidades dentro de las organizaciones, como una línea de negocio o una carga de trabajo. Las estructuras de costos se pueden basar en múltiples atributos para permitir el examen de los costos de diferentes maneras o con diferentes niveles de granularidad, por ejemplo, acumulando los costos de las cargas de trabajo individuales en la línea de negocio a la que prestan servicio. Al elegir una estructura de costos que se alinea con los resultados deseados, evalúe los mecanismos de asignación de costos en la *facilidad de implementación* frente a la *precisión deseada*. Es posible que esto incluya consideraciones relacionadas con la responsabilidad, la disponibilidad de herramientas y los cambios culturales. Tres modelos populares de asignación de costos de los que los clientes de AWS suelen partir: + **Basado en cuentas**: este modelo es el que requiere el menor esfuerzo y proporciona una alta precisión en cuanto a análisis y reintegros, y es adecuado para organizaciones que tienen una estructura contable definida (y es coherente con las recomendaciones del documento técnico [Organización del entorno de AWS con varias cuentas](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/organizing-your-aws-environment.html)). Esto proporciona una visibilidad clara de los costos por cuenta. Para la visibilidad y la asignación de los costos, puede utilizar [AWS Cost Explorer](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/ce-what-is.html), [informes de costos y uso](https://docs.aws.amazon.com/cur/latest/userguide/what-is-cur.html), así como [presupuestos de AWS](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/budgets-managing-costs.html) para el monitoreo y el seguimiento de los costos. Estas herramientas ofrecen opciones de filtrado y agrupación por Cuentas de AWS. Desde el punto de vista de la asignación de costos, este modelo no tiene por qué basarse en un etiquetado preciso de los recursos individuales. + **Basado en unidades de negocio o equipos**: el costo se puede asignar a los equipos, unidades de negocio u organizaciones de una empresa. Este modelo requiere un esfuerzo moderado, proporciona una alta precisión en cuanto a análisis y reintegros y es adecuado para organizaciones que tienen una estructura contable definida (por lo general, con AWS Organizations), con separación entre varios equipos, aplicaciones y tipos de carga de trabajo. Esto proporciona una visibilidad clara de los costos entre los equipos y las aplicaciones y, como beneficio adicional, reduce el riesgo de que se produzcan [AWS Service Quotas](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html) dentro de una sola Cuenta de AWS. Por ejemplo, cada equipo puede tener cinco cuentas (`prod`, `staging`, `test`, `dev`, `sandbox`) y no habrá dos equipos y aplicaciones que compartan la misma cuenta. Con esa estructura [Categorías de costos de AWS](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/manage-cost-categories.html) a continuación, proporcionará la funcionalidad de agrupar cuentas u otras etiquetas (“metaetiquetado”) en categorías, de las que se podrá hacer un seguimiento con las herramientas mencionadas en el ejemplo anterior. Es importante tener en cuenta que AWS Organizations permite etiquetar cuentas y unidades organizativas (OU); sin embargo, estas etiquetas no se aplicarán a los informes de asignación de costos y facturación (es decir, no puede agrupar ni filtrar los costos en AWS Cost Explorer por unidad organizativa). AWS Las categorías de costos se deben usar para este propósito. + **Basado en etiquetas**: este modelo requiere más esfuerzo en comparación con los dos anteriores y proporcionará una alta precisión en los análisis y reintegros, según los requisitos y el objetivo final. Aunque le recomendamos encarecidamente que adopte las prácticas descritas en el documento técnico [Organización del entorno de AWS con varias cuentas](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/organizing-your-aws-environment.html), siendo realistas, los clientes suelen encontrarse con estructuras de cuentas mixtas y complejas que requieren tiempo para migrar. En este escenario, la clave es implementar una estrategia de etiquetado rigurosa y eficaz, seguida de [activar las etiquetas relevantes para la asignación de costos](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/activating-tags.html) en la consola de administración de facturación y costos (en AWS Organizations, las etiquetas se pueden activar para la asignación de costos solo desde la cuenta de administración del pagador). Una vez activadas las etiquetas para la asignación de costos, se pueden utilizar las herramientas de visibilidad y asignación de costos que se mencionaron en los métodos anteriores para los análisis y los reintegros. Tenga en cuenta que las etiquetas de asignación de costos no son retrospectivas y solo aparecerán en las herramientas de informes de facturación y seguimiento de costos una vez que se hayan activado para la asignación de costos. En resumen, si necesita realizar un seguimiento de los costos por unidad de negocio, puede utilizar [Categorías de costos de AWS](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/manage-cost-categories.html) para agrupar las cuentas enlazadas dentro de la organización de AWS en consecuencia y consultar esta agrupación en los informes de facturación. Al crear cuentas independientes para los entornos de producción y que no sean de producción, también puede filtrar los costos relacionados con los entornos en herramientas como [AWS Cost Explorer](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/ce-what-is.html) o realizar un seguimiento de esos costos mediante [AWS Budgets](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/budgets-managing-costs.html). Por último, si el caso de uso requiere un seguimiento de los costos más detallado, por ejemplo, mediante cargas de trabajo o aplicaciones individuales, puede etiquetar los recursos de esas cuentas en consecuencia, [activar esas claves de etiquetas para la asignación de costos](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/activating-tags.html) en la cuenta de administración y, a continuación, filtrar ese costo por claves de etiquetas en las herramientas de informes de facturación. ## Establecimiento de los procesos de informes y monitoreo de costos Comience por identificar los tipos de costos que son importantes para las partes interesadas internas (por ejemplo, el gasto diario, el costo por cuenta, el costo por X, los costos amortizados). De este modo, podrá mitigar los riesgos presupuestarios asociados a los gastos inesperados o anómalos más rápido que esperar a la factura de AWS finalizada. Las etiquetas proporcionan la atribución que permite estos escenarios de informes. La información obtenida a partir de los informes puede servir de base para las acciones a fin de mitigar el impacto de los gastos anómalos e inesperados en los presupuestos financieros. Cuando se produce un aumento inesperado de los costos, es importante evaluar si se ha producido un aumento imprevisto en el valor entregado para poder determinar si es necesario tomar medidas y qué medidas son necesarias. Al desarrollar una estrategia de etiquetado para respaldar la asignación de costos, tenga en cuenta los siguientes elementos: + **AWS Organizations**: la asignación de costos en varias cuentas se puede realizar por cuenta, grupo de cuentas o grupo de etiquetas creadas para los recursos de esas cuentas. Las etiquetas creadas para los recursos que residen en cuentas individuales en AWS Organizations solo se pueden usar para la asignación de costos desde la cuenta de administración. + **Cuenta de AWS**: la asignación de costos dentro de una Cuenta de AWS se puede realizar mediante dimensiones adicionales, como servicios o regiones. Es posible etiquetar aún más los recursos de una cuenta y trabajar con los grupos de dichas etiquetas de recursos. + **Etiquetas de asignación de costos**: las etiquetas creadas por el usuario y las etiquetas generadas por AWS se pueden activar para la asignación de costos, si es necesario. La habilitación de las etiquetas para la asignación de costos en la consola de facturación (de la cuenta de administración en AWS Organizations) ayuda con los análisis y los reintegros. + **Categorías de costos**: las categorías de costos de AWS permiten agrupar cuentas y agrupar etiquetas (“metaetiquetado”) dentro de una organización de AWS, que además brinda la capacidad de analizar los costos relacionados con estas categorías a través de herramientas como AWS Cost Explorer, presupuestos de AWS e informes de costo y uso de AWS. ## Realización de análisis y reintegros para las unidades de negocio, los equipos u organizaciones de la empresa Atribuya los costos mediante el proceso de asignación de costos respaldado por la estructura de costos y las etiquetas de asignación de costos. Las etiquetas se pueden utilizar para proporcionar análisis a los equipos que no son directamente responsables de pagar los costos, pero que son responsables de haberlos generado. Este enfoque permite conocer la contribución al gasto y la forma en que se incurre en esos costos. Realice el reintegro a los equipos directamente responsables de los costos para recuperar el gasto de los recursos que han consumido y darles a conocer esos costos y la forma en que se han producido. ## Medición y circulación de los KPI de eficacia o valor Acuerde un conjunto de métricas de costo unitario o KPI para medir el impacto de las inversiones de administración financiera en la nube. Este ejercicio crea un lenguaje común entre las partes interesadas en la tecnología y la empresa, y cuenta una historia basada en la eficacia, en lugar de una historia centrada solo en el gasto agregado absoluto. Para obtener información adicional, consulte este blog que habla de [cómo las métricas unitarias pueden ayudar a crear una alineación entre las funciones empresariales](https://aws.amazon.com/blogs/aws-cloud-financial-management/unit-metrics-help-create-alignment-between-business-functions/). ## Asignación de gastos no asignables En función de las prácticas contables de la organización, es posible que los diferentes tipos de cargos requieran un tratamiento diferente. Identifique las categorías de recursos o costos que no se pueden etiquetar. En función de los servicios utilizados y de los que se planifique utilizar, acuerde los mecanismos sobre cómo tratar y medir ese gasto no asignable. Por ejemplo, consulte la lista de recursos admitidos por el [Editor de etiquetas y Grupos de recursos de AWS](https://docs.aws.amazon.com/ARG/latest/userguide/supported-resources.html) en la *Guía del usuario de etiquetas y Grupos de recursos de AWS*. Un ejemplo habitual de categoría de costos que no se puede etiquetar son las tarifas de los descuentos por compromiso, como las instancias reservadas (RI) y los Savings Plans (SP). Aunque las tarifas de suscripción y las tarifas de SP y RI no utilizados no se pueden etiquetar antes de que aparezcan en las herramientas de informes de facturación, puede realizar un seguimiento de cómo se aplican los descuentos de RI y SP a las cuentas, los recursos y las etiquetas en AWS Organizations después de los hechos. Por ejemplo, en AWS Cost Explorer es posible analizar el costo amortizado, agrupar ese gasto por las claves de etiquetas correspondientes y aplicar filtros adecuados al caso de uso. En informe de uso y costo (CUR) de AWS, puede filtrar las líneas que correspondan al uso cubierto por los descuentos de RI y SP (encontrará más información en la sección de casos de uso de la [Documentación de CUR](https://docs.aws.amazon.com/cur/latest/userguide/use-cases.html)) y seleccionar las columnas que solo sean relevantes para usted. Cada clave de etiqueta activada para la asignación de costos se presentará en una columna independiente al final del informe CUR, de forma similar a como se presenta en otros informes de facturación tradicionales, como el [informe mensual de asignación de costos](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/configurecostallocreport.html). Para obtener más información, consulte los [Laboratorios de Buena Arquitectura de AWS](https://www.wellarchitectedlabs.com/cost/300_labs/300_cur_queries/) para ver ejemplos de cómo obtener información sobre costos y uso a partir de los datos del CUR. ## Informes Además de las herramientas de AWS disponibles para ayudarle con los análisis y reintegros, hay una variedad de otras soluciones creadas por AWS y de terceros que pueden ayudar a monitorear el costo de los recursos etiquetados y medir la eficacia de la estrategia de etiquetado. En función de los requisitos y el objetivo final de la organización, se puede invertir tiempo y recursos en la creación de soluciones personalizadas o adquirir las herramientas proporcionadas por uno de los [Socios con competencias en herramientas de administración de Nube de 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). Si decide crear su propia herramienta de asignación de costos de *fuente única de verdad* con parámetros controlados relevantes para el negocio, el informe de uso y costo de AWS (CUR) proporciona los datos más detallados sobre costos y uso y permite crear paneles de optimización personalizados, que permiten filtrar y agrupar por cuentas, servicios, categorías de costos, etiquetas de asignación de costos y muchas otras dimensiones. Entre las soluciones basadas en CUR desarrolladas por AWS que se pueden utilizar como una de estas herramientas, compruebe [Paneles de inteligencia en la nube](https://www.wellarchitectedlabs.com/cost/200_labs/200_cloud_intelligence/) en el sitio web de Laboratorios de Buena Arquitectura de AWS. # Etiquetas para operaciones y ayuda Un entorno de AWS tendrá varias cuentas, recursos y cargas de trabajo con diferentes requisitos operativos. Las etiquetas se pueden usar para proporcionar contexto y orientación para ayudar a los equipos de operaciones a mejorar la administración de los servicios. Las etiquetas también se pueden utilizar para proporcionar transparencia en la gobernanza operativa de los recursos administrados. Algunos de los principales factores que impulsan una definición coherente de las etiquetas operativas son: + **Filtrar los recursos durante las actividades de infraestructura automatizadas.** Por ejemplo, al implementar, actualizar o eliminar recursos. Otro es el escalado de los recursos para optimizar los costos y reducir el uso fuera del horario laboral. Consulte la solución del [programador de instancias de AWS](https://aws.amazon.com/solutions/implementations/instance-scheduler/) para un ejemplo práctico. + **Identificar recursos aislados u obsoletos.** Los recursos que hayan sobrepasado su vida útil definida o que se hayan señalado por mecanismos internos para su aislamiento deberían estar debidamente etiquetados para ayudar al personal de apoyo en su investigación. Los recursos obsoletos se deben etiquetar antes de aislarlos, archivarlos y eliminarlos. + **Requisitos de soporte para un grupo de recursos.** Los recursos suelen tener requisitos de soporte diferentes; por ejemplo, estos requisitos se podrían negociar entre equipos o establecerse como parte de la importancia crítica de una aplicación. Puede encontrar más información sobre los modelos operativos en el [Pilar de excelencia operativa](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/operating-model.html). + **Mejore el proceso de administración de incidentes.** Al etiquetar los recursos con etiquetas que ofrezcan una mayor transparencia en el proceso de administración de incidentes, los equipos de soporte e ingenieros, así como los equipos de administración de incidentes graves (MIM), pueden administrar los eventos de forma más eficaz. + **Copias de seguridad.** Las etiquetas también se pueden usar para identificar la frecuencia con la que se deben hacer copias de seguridad de los recursos y dónde deben ir las copias de seguridad o dónde restaurarlas. [Guía prescriptiva sobre los enfoques de copia de seguridad y recuperación en AWS](https://docs.aws.amazon.com/prescriptive-guidance/latest/backup-recovery/welcome.html). + **Aplicación de parches.** Aplicar parches a las instancias mutables que se ejecutan en AWS es crucial para la estrategia general de aplicación de parches y para aplicar parches a las vulnerabilidades de día cero. Puede encontrar información más detallada sobre la estrategia más amplia de aplicación de parches en la [orientación prescriptiva](https://docs.aws.amazon.com/prescriptive-guidance/latest/patch-management-hybrid-cloud/welcome.html). En este [blog](https://aws.amazon.com/blogs/mt/avoid-zero-day-vulnerabilities-same-day-security-patching-aws-systems-manager/) se analiza la aplicación de parches a las vulnerabilidades de día cero. + **Observabilidad operativa**. Tener una estrategia de KPI operativa traducida en etiquetas de recursos ayudará a los equipos de operaciones a realizar un mejor seguimiento del cumplimiento de los objetivos para mejorar los requisitos empresariales. El desarrollo de una estrategia de KPI es un tema independiente, pero suele centrarse en una empresa que opera de forma estable o en dónde medir el impacto y los resultados del cambio. El [Panel de KPI](https://wellarchitectedlabs.com/cost/200_labs/200_cloud_intelligence/cost-usage-report-dashboards/dashboards/2c_kpi_dashboard/) (Laboratorios de Buena Arquitectura de AWS) y el taller de KPI de operaciones (un [servicio proactivo de AWS Enterprise Support](https://aws.amazon.com/premiumsupport/technology-and-programs/proactive-services/)) abordan la medición del rendimiento en un estado estable. El artículo del blog de estrategia empresarial de AWS [Medir el éxito de la transformación](https://aws.amazon.com/blogs/enterprise-strategy/measuring-the-success-of-your-transformation/), analiza la medición de los KPI para un programa de transformación, como la modernización de TI o la migración de en las instalaciones a AWS. # Actividades de infraestructura automatizadas Las etiquetas se pueden utilizar en una amplia gama de actividades de automatización al administrar la infraestructura. El uso de [AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/index.html), por ejemplo, le permitirá administrar las automatizaciones y los manuales de procedimientos en los recursos especificados por el par clave-valor definido que cree. En el caso de los nodos administrados, puede definir un conjunto de etiquetas para rastrear o dirigir los nodos por sistema operativo y entorno. A continuación, puede ejecutar un script de actualización para todos los nodos de un grupo o revisar el estado de esos nodos. Los [recursos de Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/taggable-resources.html) también se pueden etiquetar para refinar y rastrear aún más las actividades automatizadas. La automatización del ciclo de vida de inicio y finalización de los recursos del entorno puede proporcionar una reducción de costos significativa para cualquier organización. El [programador de instancias en AWS](https://aws.amazon.com/solutions/implementations/instance-scheduler/) es un ejemplo de solución que puede iniciar y detener instancias de Amazon EC2 y Amazon RDS cuando no son necesarias. Por ejemplo, los entornos de desarrolladores que utilizan instancias de Amazon EC2 o Amazon RDS que no tienen que funcionar los fines de semana no aprovechan el potencial de ahorro de costos que puede ofrecer el apagado de esas instancias. Al analizar las necesidades de los equipos y los entornos y etiquetar adecuadamente estos recursos para automatizar su administración, podrá utilizar el presupuesto de forma eficaz. *Un ejemplo de etiqueta de programación utilizada por el programador de instancias en una instancia de Amazon EC2:* ``` { "Tags": [ { "Key": "Schedule", "ResourceId": "i-1234567890abcdef8", "ResourceType": "instance", "Value": "mon-9am-fri-5pm" } ] } ``` # Ciclo de vida de la carga de trabajo **Revise la precisión de los datos operativos de soporte.** Asegúrese de que se realicen revisiones periódicas de las etiquetas asociadas al ciclo de vida de la carga de trabajo y de que las partes interesadas correspondientes participen en estas revisiones. *Tabla 7: Revise las etiquetas operativas como parte del ciclo de vida de la carga de trabajo* | Caso de uso | Clave de etiqueta | Justificación | Valores de ejemplo | | --- | --- | --- | --- | | Propietario de la cuenta | example-inc:account-owner:owner | El propietario de la cuenta y los recursos que contiene. | ops-center, dev-ops, app-team | | Revisión de propietario de cuenta | example-inc:account-owner:review | Compruebe si los detalles de propiedad de la cuenta están actualizados y son correctos. | | | Propietario de los datos | example-inc:data-owner:owner | El propietario de los datos de las cuentas en las que residen los datos. | bi-team, logistics, security | | Revisión del propietario de los datos | example-inc:data-owner:review | Revise si los detalles de propiedad de los datos están actualizados y son correctos. | | ## Asignación de etiquetas a las cuentas suspendidas antes de migrar a la unidad organizativa suspendida Antes de suspender una cuenta y pasar a la unidad organizativa suspendida, tal y como se detalla en el documento técnico de [Organización del entorno de AWS con varias cuentas](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/organizing-your-aws-environment.html), se deben agregar etiquetas a la cuenta para facilitar el seguimiento interno y la auditoría del ciclo de vida de una cuenta. Por ejemplo, una URL relativa o una referencia de ticket en un sistema de emisión de tickets ITSM de una organización, que muestre el registro de auditoría de una solicitud suspendida. *Tabla 8: Agregar etiquetas operativas cuando el ciclo de vida de la carga de trabajo ingrese en una nueva etapa* | Caso de uso | Clave de etiqueta | Justificación | Valores de ejemplo | | --- | --- | --- | --- | | Propietario de la cuenta | example-inc:account-owner:owner | El propietario de la cuenta y los recursos que contiene. | ops-center, dev-ops, app-team | | Propietario de los datos | example-inc:data-owner:owner | El propietario de los datos de las cuentas en las que residen los datos. | bi-team, logistics, security | | Fecha de suspensión | example-inc:suspension:date | La fecha en que se suspendió la cuenta | | | Aprobación para suspensión | example-inc:suspension:approval | El enlace a la aprobación de la suspensión de la cuenta | workload/deprecation | # Administración de incidentes Las etiquetas pueden desempeñar un papel fundamental en todas las fases de la administración de incidentes, desde el registro, la priorización, la investigación, la comunicación y la resolución de los incidentes hasta su cierre. Las etiquetas pueden detallar dónde se debe registrar un incidente, el equipo o los equipos a los que se debe informar del incidente y la prioridad de escalamiento definida. Es importante recordar que las etiquetas no están cifradas, así que tenga en cuenta la información que almacena en ellas. Además, en las organizaciones, los equipos y las estructuras jerárquicas, las responsabilidades cambian, así que considere la posibilidad de almacenar un enlace a un portal seguro donde esta información se pueda administrar de forma más eficaz. No es necesario que estas etiquetas sean exclusivas. Por ejemplo, el ID de la aplicación se podría usar para buscar las rutas de escalamiento en un portal de administración de servicios de TI. Asegúrese de que en las definiciones operativas quede claro que esta etiqueta se utiliza para varios fines. Las etiquetas de requisitos operativos también se pueden detallar para ayudar a los mánager de incidentes y al personal de operaciones a refinar aún más los objetivos en respuesta a un incidente o evento. Se pueden incluir enlaces relativos (a la URL de la base del sistema de conocimiento) para [manuales de procedimientos](https://wa.aws.amazon.com/wellarchitected/2020-07-02T19-33-23/wat.concept.runbook.en.html) y [cuadernos de trabajo](https://wa.aws.amazon.com/wellarchitected/2020-07-02T19-33-23/wat.concept.playbook.en.html) como etiquetas para ayudar a los equipos que respondieron a identificar el proceso, el procedimiento y la documentación correspondientes. *Tabla 9: Utilice etiquetas operativas para informar sobre la administración de incidentes* | Caso de uso | Clave de etiqueta | Justificación | Valores de ejemplo | | --- | --- | --- | --- | | Administración de incidentes | example-inc:incident-management:escalationlog | El sistema que utiliza el equipo de apoyo para registrar los incidentes | jira, servicenow, zendesk | | Administración de incidentes | example-inc:incident-management:escalationpath | Ruta de escalada | ops-center, dev-ops, app-team | | Asignación de costos y administración de incidentes | example-inc:cost-allocation:CostCenter | Monitorear los costos por centro de costos. Este es un ejemplo de una etiqueta de doble uso en la que el centro de costos se utiliza como código de aplicación para el registro de incidentes | 123-\$1 | | Programar copias de seguridad | example-inc:backup:schedule | Programación de copia de seguridad del recurso | Daily | | Manual/Administración de incidentes | example-inc:incident-management:playbook | Manual documentado | webapp/incident/playbook | # Aplicación de parches Las organizaciones pueden automatizar la estrategia de aplicación de parches para entornos informáticos mutables y mantener las instancias mutables en línea con la línea de base de revisiones definida para ese entorno de aplicaciones mediante el administrador de parches de AWS Systems Manager y AWS Lambda. Se puede administrar una estrategia de etiquetado para instancias mutables en estos entornos asignando dichas instancias a **Grupos de parches** y **Periodos de mantenimiento**. Consulte los siguientes ejemplos para ver una división Dev → Test → Prod. La guía prescriptiva de AWS está disponible para la [administración de parches de instancias mutables.](https://docs.aws.amazon.com/prescriptive-guidance/latest/patch-management-hybrid-cloud/welcome.html) *Tabla 10: Las etiquetas operativas pueden ser específicas del entorno* | Desarrollo | Staging | Producción | | --- | --- | --- | | 
{
"Tags": [
{
"Key": "Maintenance Window",
"ResourceId": "i-012345678ab9ab111",
"ResourceType": "instance",
"Value": "cron(30 23 ? * TUE#1 *)"
},
{
"Key": "Name",
"ResourceId": "i-012345678ab9ab222",
"ResourceType": "instance",
"Value": "WEBAPP"
},
{
"Key": "Patch Group",
"ResourceId": "i-012345678ab9ab333",
"ResourceType": "instance",
"Value": "WEBAPP-DEV-AL2"
}
]
}
| 
{
"Tags": [
{
"Key": "Maintenance Window",
"ResourceId": "i-012345678ab9ab444",
"ResourceType": "instance",
"Value": "cron(30 23 ? * TUE#2 *)"
},
{
"Key": "Name",
"ResourceId": "i-012345678ab9ab555",
"ResourceType": "instance",
"Value": "WEBAPP"
},
{
"Key": "Patch Group",
"ResourceId": "i-012345678ab9ab666",
"ResourceType": "instance",
"Value": "WEBAPP-TEST-AL2"
}
]
}
| 
{
"Tags": [
{
"Key": "Maintenance Window",
"ResourceId": "i-012345678ab9ab777",
"ResourceType": "instance",
"Value": "cron(30 23 ? * TUE#3 *)"
},
{
"Key": "Name",
"ResourceId": "i-012345678ab9ab888",
"ResourceType": "instance",
"Value": "WEBAPP"
},
{
"Key": "Patch Group",
"ResourceId": "i-012345678ab9ab999",
"ResourceType": "instance",
"Value": "WEBAPP-PROD-AL2"
}
]
}
| Las vulnerabilidades de día cero también se pueden administrar definiendo etiquetas para complementar la estrategia de aplicación de parches. Consulte [Evite las vulnerabilidades de día cero con la aplicación de parches de seguridad el mismo día mediante AWS Systems Manager](https://aws.amazon.com/blogs/mt/avoid-zero-day-vulnerabilities-same-day-security-patching-aws-systems-manager/) para obtener una orientación detallada. # Observabilidad operativa La observabilidad es necesaria para obtener información útil sobre el rendimiento de los entornos y ayudarle a detectar e investigar los problemas. También tiene un propósito secundario que le permite definir y medir los indicadores clave de rendimiento (KPI) y los objetivos de nivel de servicio (SLO), como el tiempo de actividad. Para la mayoría de las organizaciones, los KPI de operaciones importantes son el tiempo medio de detección (MTTD) y el tiempo medio de recuperación (MTTR) de un incidente. En toda la observabilidad, el contexto es importante, ya que se recopilan los datos y, a continuación, se recopilan las etiquetas asociadas. Independientemente del servicio, la aplicación o el nivel de aplicación en el que se centre, puede filtrar y analizar ese conjunto de datos específico. Las etiquetas se pueden usar para automatizar la incorporación a Alarmas de CloudWatch, de modo que se pueda avisar a los equipos adecuados cuando se superen determinados umbrales de métricas. Por ejemplo, una clave de etiqueta `example-inc:ops:alarm-tag` y el valor podrían indicar la creación de la alarma de CloudWatch. Una solución que lo demuestra se describe en [Utilice etiquetas para crear y mantener las alarmas de Amazon CloudWatch para las instancias de Amazon EC2](https://aws.amazon.com/blogs/mt/use-tags-to-create-and-maintain-amazon-cloudwatch-alarms-for-amazon-ec2-instances-part-1/). Configurar demasiadas alarmas puede provocar fácilmente una tormenta de alertas, ya que un gran número de alarmas o notificaciones abruman rápidamente a los operadores y reducen su eficacia general, mientras los operadores clasifican y priorizan manualmente las alarmas individuales. Se puede proporcionar un contexto adicional para las alarmas en forma de etiquetas, lo que significa que las reglas se pueden definir en Amazon EventBridge para garantizar que se centre en el problema inicial y no en las dependencias posteriores. A menudo se pasa por alto el rol de las operaciones junto con DevOps, pero para muchas organizaciones, los equipos de operaciones centrales siguen siendo la primera respuesta fundamental fuera del horario laboral habitual. (Se pueden encontrar más detalles sobre este modelo en el [Documento técnico sobre excelencia operativa](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/separated-aeo-ieo-with-cent-gov-and-partner.html)). A diferencia del equipo de DevOps, que es el responsable de la carga de trabajo, no suelen tener el mismo nivel de conocimiento, por lo que el contexto que proporcionan las etiquetas en los paneles y las alertas puede llevarlos al manual de procedimientos correcto para cada problema o iniciar un manual de procedimientos automatizado (consulte la publicación del blog [Automatizar las alarmas de Amazon CloudWatch con AWS Systems Manager](https://aws.amazon.com/blogs/mt/automating-amazon-cloudwatch-alarms-with-aws-systems-manager/)). # Etiquetas para la seguridad de los datos, la administración de riesgos y el control de acceso Las organizaciones tienen diferentes necesidades y obligaciones que cumplir en relación con el manejo adecuado del almacenamiento y el procesamiento de los datos. La clasificación de los datos es una precursora importante para varios casos de uso, como el control de acceso, la retención de datos, el análisis de datos y el cumplimiento. # Seguridad de datos y administración de riesgos En un entorno de AWS, es probable que tenga cuentas con diferentes requisitos de cumplimiento y seguridad. Por ejemplo, es posible que tenga un entorno aislado para desarrolladores y una cuenta que aloje el entorno de producción para una carga de trabajo altamente regulada, como el procesamiento de pagos. Al aislarlos en diferentes cuentas, puede [aplicar distintos controles de seguridad](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 el acceso a los datos confidenciales](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/benefits-of-using-multiple-aws-accounts.html#constrain-access-to-sensitive-data) y reducir el alcance de la auditoría en el caso de cargas de trabajo reguladas. La adopción de un estándar único para todas las cargas de trabajo puede generar desafíos. Aunque muchos controles se aplican por igual en todos los entornos, algunos son excesivos o irrelevantes para las cuentas que no necesitan cumplir marcos normativos específicos y para las cuentas en las que nunca habrá datos de identificación personal (por ejemplo, un entorno aislado para desarrolladores o cuentas de desarrollo de cargas de trabajo). Por lo general, esto lleva a resultados de seguridad con falsos positivos que se deben clasificar y cerrar sin tomar ninguna medida, lo que resta esfuerzo a los resultados que se deberían investigar. *Tabla 11: Ejemplos de etiquetas de seguridad de datos y administración de riesgos* | Caso de uso | Clave de etiqueta | Justificación | Valores de ejemplo | | --- | --- | --- | --- | | Administración de incidentes | example-inc:incident- management:escalationlog | El sistema que utiliza el equipo de apoyo para registrar los incidentes | jira, servicenow, zendesk | | Administración de incidentes | example-inc:incident- management:escalationpath | Ruta de escalada | ops-center, dev-ops, app-team | | Clasificación de datos | example-inc:data:classification | Clasificar los datos para garantizar el cumplimiento y el gobierno | Public, Private, Confidential, Restricted | | Conformidad | example-inc:compliance:framework | Identifica el marco de cumplimiento al que está sujeta la carga de trabajo | PCI-DSS, HIPAA | Administrar manualmente los diferentes controles en un entorno de AWS consume tiempo y es propenso a errores. El siguiente paso es automatizar la implementación de los controles de seguridad adecuados y configurar la inspección de los recursos en función de la clasificación de esa cuenta. Al aplicar etiquetas a las cuentas y a los recursos que contienen, la implementación de los controles se puede automatizar y configurar de forma adecuada para la carga de trabajo. **Ejemplo de: ** Una carga de trabajo incluye un bucket de Amazon S3 con la etiqueta `example-inc:data:classification` con el valor `Private`. La automatización de las herramientas de seguridad implementa la regla de AWS Config `s3-bucket-public-read-prohibited`, que comprueba la configuración del acceso público de bloques del bucket de Amazon S3, la política del bucket y la lista de control de acceso (ACL) del bucket para confirmar que la configuración del bucket es adecuada para la clasificación de datos. Para garantizar que el contenido del bucket sea coherente con la clasificación, [Amazon Macie se puede configurar para comprobar la información de identificación personal (PII)](https://aws.amazon.com/about-aws/whats-new/2021/05/amazon-macie-supports-criteria-based-bucket-selection-sensitive-data-discovery-jobs/). El blog [Uso de Amazon Macie para validar la clasificación de datos del bucket de S3](https://aws.amazon.com/blogs/architecture/using-amazon-macie-to-validate-s3-bucket-data-classification/) explora este patrón con mayor profundidad. Es posible que determinados entornos regulatorios, como los seguros y la atención médica, estén sujetos a políticas obligatorias de retención de datos. La retención de datos mediante etiquetas, combinada con las políticas de ciclo de vida de Amazon S3, puede ser una forma eficaz y sencilla de determinar las transiciones de objetos a un nivel de almacenamiento diferente. Las reglas del ciclo de vida de Amazon S3 también se pueden utilizar para hacer caducar los objetos para la eliminación de datos una vez transcurrido el periodo de retención obligatorio. Consulte [Simplificar el ciclo de vida de los datos mediante el uso de etiquetas de objetos con Amazon S3 Lifecycle](https://aws.amazon.com/blogs/storage/simplify-your-data-lifecycle-by-using-object-tags-with-amazon-s3-lifecycle/) para obtener una guía detallada de este proceso. Además, al clasificar o abordar el resultado de seguridad, las etiquetas pueden proporcionar al investigador un contexto importante que ayuda a calificar el riesgo y ayudan a contratar a los equipos adecuados para investigar o mitigar el resultado. # Etiquetas para administración de identidades y control de acceso Al administrar el control de acceso a través de un entorno de AWS con AWS IAM Identity Center, las etiquetas pueden habilitar varios patrones de escalado. Se pueden aplicar varios patrones de delegación, algunos se basan en el etiquetado. Los abordaremos de forma individual y proporcionaremos enlaces a lecturas adicionales sobre cada uno de ellos. # ABAC para recursos individuales Los usuarios del Centro de identidades de IAM y los roles de IAM admiten el control de acceso basado en atributos (ABAC), que permite definir el acceso a las operaciones y los recursos en función de las etiquetas. ABAC ayuda a reducir la necesidad de actualizar las políticas de permisos y a basar el acceso a los atributos de los empleados del directorio corporativo. Si ya utiliza una estrategia de varias múltiples, puede utilizar ABAC además del control de acceso basado en roles (RBAC) para proporcionar a varios equipos que operan en la misma cuenta un acceso detallado a diferentes recursos. Por ejemplo, los usuarios del Centro de identidades de IAM o los roles de IAM pueden incluir condiciones para limitar el acceso a instancias específicas de Amazon EC2 que, de lo contrario, se tendrían que mostrar de forma explícita en cada política para poder acceder a ellas. Dado que un modelo de autorización de ABAC depende de las etiquetas para acceder a las operaciones y los recursos, es importante proporcionar barreras de protección para evitar el acceso no deseado. Las SCP se pueden usar para proteger las etiquetas en toda la organización, ya que solo permiten que las etiquetas se modifiquen bajo determinadas condiciones. Los blogs [Protección de las etiquetas de recursos utilizadas para la autorización mediante una política de control de servicios en AWS Organizations](https://aws.amazon.com/blogs/security/securing-resource-tags-used-for-authorization-using-service-control-policy-in-aws-organizations/) y [Límites de permisos para las entidades de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html) proporcionan información sobre cómo implementar esto. Cuando se utilizan instancias de Amazon EC2 de larga duración para respaldar prácticas operativas más tradicionales, se puede utilizar este enfoque, el blog [Configurar ABAC de Centro de identidades de IAM para las instancias de Amazon EC2 y el administrador de sesiones de Systems Manager](https://aws.amazon.com/blogs/security/configure-aws-sso-abac-for-ec2-instances-and-systems-manager-session-manager/) analiza con más detalle esta forma de control de acceso basada en atributos. Como se mencionó anteriormente, no todos los tipos de recursos admiten el etiquetado y, de los que lo hacen, no todos admiten la aplicación mediante políticas de etiquetado, por lo que es una buena idea evaluar esto antes de empezar a implementar esta estrategia en una Cuenta de AWS. Para obtener más información sobre los servicios compatibles con ABAC, consulte [servicios de AWS que funcionan con IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html).