Etiquetas de asignación de costos: un estándar de etiquetado que sobrevive a la exportación de facturación

Objetivo

Responder «cuánto cuesta el servicio X al mes, por entorno, por equipo» a partir de la exportación de facturación del proveedor, sin hojas de cálculo manuales.

Requisitos previos

Infraestructura definida en código para la gran mayoría de los recursos; acuerdo sobre quién es responsable del informe de costos; acceso a la consola de facturación de la cuenta pagadora.

Pasos

1. Elegir un conjunto breve de claves obligatorias, típicamente service, environment, owner (equipo, no persona) y cost-center, más un component opcional. Escribir los valores permitidos; el texto libre frustra la agrupación.
2. Fijar reglas de escritura. La guía de etiquetado de AWS (citada) indica que las claves y los valores de las etiquetas distinguen mayúsculas de minúsculas, de modo que Environment=Prod y environment=prod forman dos grupos distintos; la documentación de Azure (citada) trata los nombres de etiqueta como insensibles a mayúsculas y minúsculas para las operaciones, pero los valores como sensibles. Estandarizar claves y valores en minúsculas en todas partes.
3. Activar las claves para facturación. La guía de facturación de AWS (citada) explica que las etiquetas definidas por el usuario y las generadas por AWS deben activarse cada una por separado antes de aparecer en Cost Explorer o en el informe de asignación de costos, que en una organización solo la cuenta de gestión tiene acceso al administrador de etiquetas de asignación de costos, y que las etiquetas pueden tardar hasta 24 horas en aparecer en la consola de facturación. El relleno retroactivo de etiquetas para períodos pasados está documentado como un procedimiento aparte, así que conviene activar las claves con antelación en lugar de depender de él.
4. Aplicar las etiquetas mediante las etiquetas por defecto a nivel de proveedor del código de infraestructura, de modo que todo recurso que el código cree las lleve; añadir las claves a las interfaces de los módulos para que un módulo no pueda instanciarse sin un owner.
5. Exigirlo en el momento de creación mediante políticas: una regla de denegación para la creación de recursos sin las claves obligatorias (política de la organización, Azure Policy, control de admisión en Kubernetes para volúmenes y balanceadores de carga aprovisionados en la nube).
6. No confiar en la herencia: la documentación de Azure (citada) indica que los recursos no heredan las etiquetas aplicadas a un grupo de recursos o a una suscripción, así que hay que etiquetar cada recurso explícitamente en lugar de suponer que los elementos hijos llevan las etiquetas del padre; los recursos compartidos (gateways NAT, transferencia de datos, planes de soporte) nunca se asignan limpiamente a un solo servicio.
7. Cada mes, exportar los costos agrupados por las claves obligatorias, listar el remanente sin etiquetar por servicio, y bien etiquetar los recursos, bien asignar el costo compartido según una regla escrita, o bien aceptarlo explícitamente.

Resultado esperado

Una exportación de facturación en la que la parte sin etiquetar es pequeña y está explicada, y un costo por servicio que el equipo responsable reconoce como propio.

Límites y base de verificación

Las etiquetas no capturan los recursos creados fuera del código o por servicios gestionados en nombre del cliente, y los cargos que no están asociados a un recurso etiquetable permanecen en el remanente sin etiquetar; la página de Azure citada señala que no todos los tipos de recurso admiten etiquetas. El comportamiento del proveedor sigue la documentación citada; no se afirma ninguna cifra de costo.