Leer un inventario en tablas

Cada fila del inventario describe un recurso. Las columnas comunes son el tipo, la nube, la región, la cuenta o suscripción, la fecha de creación, el equipo dueño y el entorno. Con esas siete o diez columnas se responden casi todas las preguntas de una revisión: qué hay, dónde, de quién y desde cuándo.

El error típico es usar el nombre como clave. Un nombre como «reportes» o «web» puede repetirse en otra cuenta, en otra región o en la otra nube, y entonces dos filas distintas parecen una. Lo que identifica de forma única un recurso es su identificador completo, que incluye la cuenta y, según el servicio, la región.

La fecha de creación sirve para detectar lo que pudo quedar olvidado. Un recurso muy antiguo no es un problema por sí solo, pero sí es un candidato a revisar: se creó con prácticas de otra época, quizá con permisos amplios o sin etiquetas, y nadie lo ha vuelto a mirar.

Ordenar la tabla por fecha de creación, de la más antigua a la más reciente, es la primera consulta de higiene que conviene hacer a cualquier inventario.

Un inventario sin reglas es solo una lista. La tabla de política de Sierra Brava dice, por ejemplo, que los datos de producción solo pueden estar en dos regiones. Cruzar cada fila con esa regla convierte la lista en una revisión: lo que cumple se aparta y lo que no, se anota.

Se cuenta sobre los recursos del inventario, sin importar el entorno: una región no permitida es una desviación de la política tanto en producción como en pruebas, aunque en pruebas la gravedad sea menor.

En AWS, un recurso se identifica con un ARN: una cadena que combina la partición, el servicio, la región, la cuenta y el nombre del recurso. En algunos servicios, como los buckets de almacenamiento, el ARN omite la región y la cuenta porque el nombre ya es único en todo el mundo. En Azure, el identificador es una ruta jerárquica que empieza por la suscripción y el grupo de recursos y sigue con el proveedor, el tipo y el nombre.

Para un inventario de dos nubes, esa diferencia obliga a normalizar: una columna de «cuenta» que en AWS lleva el número de cuenta y en Azure, la suscripción. Si no se normaliza, las consultas que cruzan las dos nubes fallan sin avisar.