Administración de operaciones

El diseño de tags determina las operaciones - Curiosidades y reglas de nomenclatura prácticas de la estrategia de tags de recursos AWS

Explicamos por qué los tags de recursos AWS no son simples etiquetas sino la base de la asignación de costos, control de acceso y automatización, las reglas de nomenclatura de claves de tags, cómo usar el límite de 50 tags y la gobernanza mediante políticas de tags.

約 5 分で読めます

Los tags no son simples etiquetas

Los tags de recursos AWS son una función que adjunta metadatos a los recursos mediante pares de clave y valor (ejemplo: Environment=Production, Team=Backend). A primera vista parece un simple etiquetado, pero en el ecosistema de AWS los tags cumplen 3 roles importantes. Primero, la asignación de costos. Cost Explorer y Cost and Usage Report (CUR) desglosan los costos basándose en tags, permitiendo visualizar los costos por equipo, proyecto o entorno. Segundo, el control de acceso. Las políticas IAM pueden usar condiciones basadas en tags para permitir que "solo los miembros del equipo Backend operen recursos con el tag Team=Backend". Tercero, la automatización. AWS Config puede detectar recursos sin tags específicos, y Systems Manager puede ejecutar parches solo en instancias con un tag específico.

Reglas de nomenclatura de claves de tags - Si no se deciden primero, se sufre después

Las reglas de nomenclatura de claves de tags causan confusión si no se unifican en toda la organización. Environment, environment, env, Env, ENVIRONMENT se tratan todos como claves de tags diferentes. Como las claves de tags distinguen mayúsculas y minúsculas, sin reglas de nomenclatura unificadas, el mismo significado existe en múltiples variaciones y la asignación de costos y el control de acceso no funcionan correctamente. La regla de nomenclatura recomendada es PascalCase (Environment, CostCenter, DataClassification). Esto es consistente con las claves de tags del sistema de AWS (aws:createdBy, etc.) y es fácil de leer visualmente. Otra opción es kebab-case (environment, cost-center), pero lo importante es la consistencia dentro de la organización.

Cómo usar el límite de 50 tags

El límite de tags que se pueden adjuntar a un recurso AWS es 50 (excluyendo tags del sistema con prefijo aws:). 50 puede parecer mucho, pero se consume sorprendentemente rápido a medida que la organización crece. Para asignación de costos (Environment, Team, Project, CostCenter), gestión operativa (ManagedBy, BackupPolicy, PatchGroup), seguridad (DataClassification, Compliance), y automatización (AutoShutdown, MaintenanceWindow), fácilmente se usan 15-20 tags. La clave es diseñar una taxonomía de tags desde el principio y evitar la proliferación de tags ad hoc. Definir los tags obligatorios y opcionales, y aplicarlos con políticas de tags de Organizations.

Políticas de tags - Gobernanza de tags en toda la organización

Las políticas de tags de AWS Organizations son una función que estandariza las claves y valores de tags utilizados en las cuentas de la organización. Si se define en la política de tags que "el valor del tag Environment debe ser Production, Staging o Development", se pueden detectar valores no estándar como Prod o production. Las políticas de tags tienen 2 modos: "modo de detección" y "modo de aplicación". El modo de detección solo reporta violaciones sin bloquear la creación de recursos. El modo de aplicación rechaza la creación de recursos que no cumplan con la política. Se recomienda comenzar con el modo de detección para identificar el estado actual y luego migrar gradualmente al modo de aplicación.

Trampas de la asignación de costos basada en tags

La asignación de costos basada en tags tiene trampas que se deben conocer. Primero, no todos los recursos soportan tags. Los costos de transferencia de datos, las tarifas de consultas de Route 53 y las tarifas de métricas de CloudWatch no pueden clasificarse con tags porque no están vinculados a recursos. Estos "costos no etiquetables" pueden alcanzar el 20-30% del total. Segundo, los tags de asignación de costos solo se reflejan desde el momento en que se activan. No se aplican retroactivamente, por lo que si se olvida activarlos, los costos de ese período no se pueden desglosar. Tercero, los tags adjuntados a recursos padre no se heredan automáticamente a recursos hijo. Los tags de una VPC no se propagan a las subnets o instancias EC2 dentro de ella. Para profundizar en la gestión de tags y costos de AWS, los libros especializados (Amazon) son una buena referencia.

Servicios relacionados

AWS OrganizationsServicio para gestionar centralmente múltiples cuentas de AWSAWS ConfigUn servicio que registra y evalúa cambios de configuración de recursos AWS y monitorea el cumplimiento continuamenteAWS Cost ExplorerUn servicio que visualiza y analiza los costos y uso de AWS, e identifica oportunidades de optimización

Artículos relacionados

Capacidad de diseño de gobernanza multi-cuenta en AWS - Gobernanza organizacional con Organizations, Control Tower y SCPComparamos el mecanismo de gobernanza multi-cuenta centrado en AWS Organizations, Control Tower y SCP (Service Control Policies) con Azure Management Groups, explicando la diferencia en capacidad de diseño de gobernanza empresarial.Herramientas de gestión de costos de AWS - La integración nativa de Cost Explorer, Budgets y Compute OptimizerAWS integra nativamente herramientas de gestión de costos como Cost Explorer, Budgets, Compute Optimizer y Trusted Advisor. Comparamos con Azure Cost Management y la gestión de facturación de GCP, analizando la ventaja de AWS en visibilidad y optimización de costos.Hallazgos más comunes en Well-Architected Review - 5 errores de diseño que los ingenieros pasan por altoExplicamos los problemas de diseño señalados repetidamente en AWS Well-Architected Review, centrándonos en 5 áreas: despliegue en una sola AZ, falta de backups, logs sin utilizar, optimización de costos abandonada y permisos excesivos en Security Groups.

Más sobre este tema

El mecanismo de sincronización horaria interna de AWS - Amazon Time Sync Service y el diseño de smearing de segundos intercalaresExplicamos el mecanismo de Amazon Time Sync Service operado de forma independiente por AWS, la fuente de tiempo de alta precisión con GPS y relojes atómicos, la decisión de diseño de absorber los segundos intercalares mediante smearing y la importancia de la sincronización horaria en sistemas distribuidos.Centralización de registros de auditoría SaaS con AWS AppFabric - Estandarización OCSF e integración con Security LakeExplicamos la recopilación de registros de auditoría de aplicaciones SaaS con AppFabric, la estandarización al formato OCSF y la construcción de pipelines de análisis.Implementación de Feature Flags con AWS AppConfig - Despliegue seguro de configuración y rollbackDespliega cambios de configuración de forma independiente al código mediante estrategias Linear y Exponential. Garantiza la seguridad con rollback automático activado por alarmas de CloudWatch.Revisión de arquitectura - Evaluación sistemática de cargas de trabajo con AWS Well-Architected ToolExplica la revisión de arquitectura de cargas de trabajo usando AWS Well-Architected Tool. Presenta la evaluación basada en 6 pilares, la elaboración de planes de mejora y el uso de lentes personalizados.Diseño y operación de logs de auditoría - Registro completo de actividad API con CloudTrailExplica las técnicas de diseño de logs de auditoría con AWS CloudTrail, el registro de actividad API, el almacenamiento a largo plazo en S3 y la respuesta de cumplimiento mediante integración con Config.Lecciones de sistemas distribuidos de los informes de incidentes (COE) de AWS - Principios de diseño que cambiaron las grandes interrupciones del pasadoA partir de los Correction of Errors (COE) e informes de incidentes publicados por AWS, explicamos las causas raíz de grandes incidentes pasados como la interrupción de S3, la interrupción de DNS en us-east-1 y la interrupción de Kinesis, y cómo cambiaron los principios de diseño de AWS.Por qué existen las cuotas de servicio de AWS - Diseño multitenant que protege la infraestructura compartidaExplicamos que las cuotas de servicio de AWS (antes límites de servicio) no son simples restricciones sino un diseño para proteger a otros clientes en un entorno multitenant, desde el problema del vecino ruidoso, la diferencia entre límites soft y hard, y el trasfondo de las solicitudes de aumento.Gestion centralizada de backups con AWS Backup - Planes de backup y proteccion cross-regionGestione backups de EC2, RDS, DynamoDB y mas bajo una politica unificada. Cubre la proteccion WORM con Vault Lock y la automatizacion de pruebas de restauracion.

Artículos y servicios similares

AWS Cost ExplorerHerramienta de gestión de costos que visualiza y analiza los costos de uso y consumo de AWS mediante gráficos y filtros, con capacidad de predicción de costos futurosAWS ConfigServicio que registra y evalúa continuamente los cambios de configuración de recursos AWS, logrando auditoría automatizada basada en reglas de compliance y seguimiento del historial de configuraciónConstrucción de una plataforma de análisis de datos industriales con AWS IoT SiteWise - Recopilación de datos de equipos y modelado de activosRecopile datos de equipos industriales con edge gateways, estructúrelos con modelos de activos y visualícelos en dashboards. Presentamos una plataforma de análisis de datos de equipos compatible con OPC-UA.Visualización y análisis de costos - Optimización de gastos en la nube con AWS Cost ExplorerTécnicas de visualización y análisis de costos en la nube con AWS Cost Explorer. Monitoreo de uso con métricas de CloudWatch y enfoques prácticos para la optimización de costos.Gestion centralizada de backups con AWS Backup - Planes de backup y proteccion cross-regionGestione backups de EC2, RDS, DynamoDB y mas bajo una politica unificada. Cubre la proteccion WORM con Vault Lock y la automatizacion de pruebas de restauracion.