Snapshots huérfanos: la factura oculta de los backups y cómo limpiarla con aprobación

Los snapshots son el recurso cloud más fácil de olvidar. No aparecen en ningún panel de recursos activos, no generan métricas de uso y su coste crece tan despacio que nadie lo nota. Hasta que alguien revisa la factura y descubre que lleva años pagando copias de discos que ya no existen. En este artículo te contamos cómo detecta AAA Sentinel esos snapshots huérfanos en AWS y cómo limpiarlos con el Agente IA sin perder el control: cada borrado se propone, se aprueba, espera un período de gracia y después se mide.

Cómo se acumulan

Casi siempre por una de estas cuatro vías:

• Backups automáticos sin retención: alguien programó un snapshot diario y nunca definió cuántos guardar.
• Copias «por si acaso»: antes de una migración o de una actualización se hace un snapshot, todo va bien y nadie lo borra.
• AMIs antiguas: en AWS, cada AMI crea un snapshot por cada volumen. Las versiones viejas de una imagen arrastran sus snapshots.
• Volúmenes borrados: el disco se elimina, pero sus snapshots no. Son los snapshots huérfanos, y nadie los asocia ya a nada.

Lo que cuesta

En AWS, un snapshot EBS estándar cuesta unos 0,05 US$ por GB al mes en us-east-1, y Azure y Google Cloud tienen precios del mismo orden. Parece poco, pero se acumula: 3 TB de snapshots olvidados son unos 150 US$ al mes, cada mes, sin que nadie se beneficie de ellos.

Qué ganas con ello

Con la detección y el agente trabajando juntos:

• Ves todos los snapshots huérfanos de tus cuentas de AWS en Hallazgos activos, con su coste estimado.
• Los borras sin entrar en la consola, y sin que nadie borre nada por su cuenta: cada borrado lo aprueba una persona.
• Tienes un margen para arrepentirte antes de que se ejecute y un historial de quién aprobó qué.
• Sabes después si el gasto de la cuenta bajó de verdad, no sólo lo que se estimaba.

Qué detecta AAA Sentinel

La regla STORAGE_ORPHAN_SNAPSHOT, incluida en todos los planes y en la prueba de 30 días, revisa los snapshots EBS propios de cada región de AWS y señala los que se crearon a partir de un volumen que ya no existe en la cuenta. Cada uno genera un hallazgo de severidad alta, «Snapshot huérfano», con un ahorro estimado igual al tamaño del volumen de origen por 0,05 US$ por GB al mes.

• No hay ninguna regla por antigüedad. Un snapshot de hace tres años cuyo volumen sigue existiendo no genera hallazgo; uno de ayer cuyo volumen se borró, sí.
• Es una regla de AWS. Los snapshots de Azure y de Google Cloud, los de RDS y las AMIs no se analizan.
• Un snapshot que respalda una AMI registrada también aparece como huérfano si su volumen ya no existe. AWS no permite borrarlo mientras la AMI exista, así que revísalo antes.

Caso práctico: los snapshots de ACME

ACME, una empresa ficticia en el plan Business, conecta su cuenta de AWS de producción. El primer escaneo encuentra esto:

Paso 1: encontrar los snapshots huérfanos

En Hallazgos activos, elige la cuenta en el selector y la pestaña Alto. Los snapshots huérfanos aparecen como «Snapshot huérfano», seguidos del nombre o del identificador del snapshot. Al abrir uno, el «Detalle del hallazgo» muestra la «Recomendación»: bórralo si no lo necesitas para recuperación ante desastres, pero comprueba antes que no sea la única copia de datos críticos. Si decides conservar alguno, márcalo como «Descartado» para que deje de contar en los indicadores.

Paso 2: preparar el agente

El Agente IA está en el plan Business y necesita permisos de escritura. Al conectar la cuenta, el paso «Habilitar agente autónomo (opcional)» crea un segundo rol, separado del de solo lectura. Ese rol puede borrar snapshots y volúmenes desmontados; a diferencia de las acciones sobre instancias EC2, borrar un snapshot no exige la etiqueta FinOpsSentinelManaged=true, así que la aprobación es tu control principal.

Paso 3: activar el playbook

En Agente IA → Playbooks, mientras no tengas ningún playbook verás las «Plantillas predefinidas». La que nos interesa es old-snapshots-cleanup, «Limpieza de snapshots antiguos». Al usarla eliges la cuenta y el playbook queda creado con esta configuración:

• Se evalúa al terminar cada escaneo de esa cuenta, sobre sus hallazgos de severidad media o superior.
• Selecciona los hallazgos de snapshots EBS con más de 90 días desde su creación. Como el único hallazgo de snapshots es el de snapshot huérfano, en la práctica son snapshots huérfanos con más de 90 días.
• Propone la acción de borrar el snapshot, siempre pendiente de aprobación y con 48 horas de período de gracia.
• Propone como mucho 10 acciones por escaneo. El botón «Ejecutar» lo evalúa en el momento contra el último escaneo y elige los 10 con más ahorro.

Paso 4: aprobar o rechazar

Las propuestas aparecen en Agente IA → Panel, en «Pendientes de aprobación», con el recurso, el motivo y el ahorro estimado. Las personas con rol de propietario, administrador o aprobador reciben además un email con un enlace para revisarlas en la plataforma.

• «Aprobar» la pasa a la cola de ejecución. «Rechazar» la descarta e incluye el motivo. «Cancelar propuesta» la retira.
• Una propuesta que nadie aprueba en 7 días caduca sola.
• Algunas acciones exigen una segunda aprobación de otra persona distinta. Hoy son las correcciones de seguridad, como cerrar puertos de administración o bloquear el acceso público a un bucket. Borrar un snapshot necesita una sola.
• En ACME, la persona que aprueba rechaza los dos snapshots que respaldan una AMI en uso y aprueba los otros siete.

Paso 5: el período de gracia

La aprobación no ejecuta nada todavía. La acción pasa a «Aprobadas — esperando ejecución», con la fecha en «Se ejecutará:», y espera el período de gracia: 48 horas para borrar un snapshot. Cuando faltan 4 horas o menos, los aprobadores reciben un recordatorio por email. Hasta ese momento, «Cancelar propuesta» la detiene sin consecuencias.

Paso 6: la ejecución, y lo que no se puede deshacer

Pasado el período de gracia, el agente comprueba que el snapshot sigue existiendo y lo borra. Si algo falla, los aprobadores reciben un email con el error. Cada acción queda en Agente IA → Historial, y su detalle incluye el apartado «Rollback» con lo que se puede hacer para revertirla.

• Borrar un snapshot no se puede deshacer. El propio historial lo dice: el snapshot se ha eliminado de forma permanente. Salvo que tengas la Papelera de reciclaje de AWS configurada, no hay vuelta atrás.
• El botón «Deshacer» sólo aparece en las acciones que guardaron el valor anterior, como aplicar etiquetas.
• Borrar un volumen sin montar es distinto: antes de borrarlo, el agente crea un snapshot de respaldo y el historial te deja el comando para recrear el volumen a partir de él.

Paso 7: verificar el ahorro

El Panel separa dos cifras: «Ahorro estimado (ejecutado)», que suma lo que estimaban las reglas, y «Ahorro verificado», que se mide contra el coste real. Como no hay facturación por recurso, la verificación compara el ritmo de gasto diario de toda la cuenta antes y después de la acción, a partir de los escaneos.

• No se intenta hasta que han pasado al menos 7 días desde la ejecución.
• Si el gasto de la cuenta no baja, la acción queda como no confirmada, nunca como un ahorro negativo.
• Si en esos días se ejecutaron otras acciones en la misma cuenta, la confianza de la cifra baja, porque no se puede aislar el efecto de cada una.

La prevención: políticas de retención

Limpiar lo que hay es la mitad del trabajo; la otra mitad es que no vuelva a acumularse. Los tres proveedores lo resuelven con herramientas propias:

• AWS: Data Lifecycle Manager o AWS Backup crean los snapshots y los borran por número o por antigüedad. Para lo que tienes que guardar mucho tiempo, el nivel de archivo de snapshots cuesta unos 0,0125 US$ por GB al mes, con un mínimo de 90 días y un coste por restaurar.
• Azure: las políticas de Azure Backup definen cuánto se conserva cada copia.
• Google Cloud: las programaciones de snapshots incluyen los días de retención.
• Una guía de partida: en producción, diarios de 7 días, semanales de 4 semanas y mensuales de 3 meses; en staging, 3 días; en desarrollo, normalmente ninguno; y los snapshots manuales, con una etiqueta de fecha de caducidad.

Lo que no hace todavía

Para que sepas dónde están los límites:

• No hay regla por antigüedad ni para snapshots cuyo volumen sigue existiendo.
• Sólo snapshots EBS de AWS: ni Azure, ni Google Cloud, ni RDS, ni AMIs.
• Cada escaneo lee hasta 500 snapshots por región.
• El ahorro estimado usa el tamaño del volumen de origen y no tiene en cuenta que los snapshots son incrementales.
• Un playbook no vuelve a proponer una acción que ya está pendiente o aprobada, ni actúa sobre hallazgos descartados o resueltos. Si rechazas una propuesta, el siguiente escaneo puede volver a hacerla: para que deje de proponerla, descarta el hallazgo.
• La plantilla unused-volumes-cleanup, «Limpieza de volúmenes sin usar», propone borrar volúmenes que llevan más de 30 días sin montar. El plazo cuenta desde el primer escaneo que lo vio desmontado, no desde que se creó, y vuelve a cero si se monta de nuevo. En las tres nubes, antes de borrar se guarda un snapshot de respaldo; si no se puede crear, no se borra nada.

Checklist para empezar

Con esto en orden, los snapshots dejan de ser una factura que nadie revisa:

• Tus cuentas de AWS conectadas y un escaneo revisado en Hallazgos activos.
• Los snapshots que respaldan AMIs en uso y las copias que quieres guardar, identificados.
• Plan Business, el rol del agente creado y, si quieres red de seguridad, una regla de la Papelera de reciclaje de AWS.
• El playbook old-snapshots-cleanup activado o uno creado desde el hallazgo con «Convertir en playbook».
• Alguien con rol de aprobador pendiente del Panel y de los emails.
• Una política de retención en cada nube para que no vuelvan a acumularse.