AWS Backup añade soporte nativo para Amazon EKS: adiós a los scripts

AWS está transformando la forma en que las empresas gestionan la recuperación ante desastres en Kubernetes, con poca fanfarria pero con consecuencias palpables.

Con la llegada oficial del soporte nativo para Amazon EKS en AWS Backup, puedes despedirte de scripts engorrosos, herramientas de terceros sujetas con alfileres y depuraciones interminables de YAML. El lanzamiento deja las cosas claras: el backup y la restauración en Kubernetes ya no tienen por qué ser un mosaico caótico de utilidades dispersas y procesos manuales.

A continuación analizamos qué supone esto para los equipos reales de DevOps, qué opina la comunidad técnica y por qué esta función puede redefinir la gestión del estado, la escala y la seguridad en EKS.

La forma antigua: scripts caseros y un mar de herramientas

Antes de esta actualización, respaldar tus clústeres de Amazon EKS resultaba, por decirlo de forma suave, una tarea "artesanal". La mayoría de los equipos escribían sus propios scripts de backup o recurrían a opciones de terceros como Velero, que, aunque popular, introducía complicaciones añadidas.

Te veías obligado a:

• Desarrollar y mantener scripts de backup para cada clúster
• Lidiar con cambios de compatibilidad y actualizaciones de versiones
• Configurar manualmente roles de IAM, destinos de almacenamiento, cifrado y versionado
• Rezar para que el proceso de restauración respondiera de verdad en una emergencia

Algunas organizaciones lograron estabilizar Velero, pero otras no tuvieron tanta suerte. Un usuario resumió el sentir general en un foro de Kubernetes: "Esto me alegra. No me hace especial gracia depender de Velero tras lo que pasó con VMware."

Ese comentario encierra más que simple frustración. La adquisición de Velero y la incertidumbre en torno a su integración bajo VMware generaron inquietud en muchos equipos empresariales sobre el futuro del proyecto. Por eso, el paso al frente de AWS con una alternativa nativa llega en un momento oportuno y promete aliviar notablemente a los equipos de operaciones.

La nueva forma: nativa, centralizada y basada en políticas

AWS Backup ahora trata a Amazon EKS como un recurso de primera categoría. Esto implica:

• Olvidarte de programar cada escenario de restauración
• Eliminar la dependencia de software de terceros
• Centralizar la gestión de copias en la misma consola que ya utilizas para EC2, RDS, EFS y otros servicios

Por debajo, la solución opera respaldando tanto la configuración del clúster de EKS (como deployments, services, configmaps y secrets) como los datos persistentes vinculados (en EBS, EFS o, de forma opcional, S3).

Llegado el momento de restaurar, AWS puede aprovisionar un clúster de EKS nuevo a partir de tus parámetros originales y coordinar la recuperación de forma automática. Esto cierra el círculo de la automatización de infraestructura y suprime una enorme complejidad técnica.

Cómo funciona en la práctica

Este es el procedimiento paso a paso:

1. Habilita el servicio: dirígete a la configuración de AWS Backup y activa EKS como recurso protegido.
2. Crea el backup: genera una copia bajo demanda de tu clúster de EKS en ejecución (o prográmala mediante políticas).
3. Selecciona tu rol: elige un rol de IAM con los permisos pertinentes de backup y restauración.
4. Restaura: selecciona el punto de recuperación deseado y restaura sobre un clúster existente o permite que AWS levante uno nuevo.
5. Valida: AWS Backup restaurará los recursos de Kubernetes y los volúmenes persistentes, facilitando la inspección del estado recuperado.

Si te parece excesivamente sencillo, esa es justo la idea. El mismo panel centraliza ahora snapshots de EC2, recuperaciones puntuales de RDS y restauraciones integrales de clústeres de EKS en un único punto.

Por qué importa (incluso si crees que no lo necesitas)

En la comunidad de Kubernetes persiste la creencia común de que no hace falta hacer backups de los clústeres porque las cargas de trabajo son efímeras y los datos residen fuera, ya sea en S3, RDS o DynamoDB.

Un usuario lo expresaba así: "¿Por qué iba a necesitar respaldar mis clústeres de EKS? Todas mis cargas de trabajo son efímeras."

Varios profesionales no tardaron en matizarlo con razón. Kubernetes almacena una enorme cantidad de "estado" que no habita en bases de datos externas:

• ConfigMaps
• Secrets
• Certificados TLS
• Claves generadas dentro del clúster
• Metadatos de Helm
• Estado de Argo CD
• Configuraciones de controladores de admisión (admission controllers)

A esto se suman los imprevistos habituales, como cuando un desarrollador aplica un ajuste urgente en caliente y olvida registrarlo en Git. Como apuntaba un comentario: "¿Acaso alguien en algún equipo no ha hecho alguna vez un cambio que olvidó confirmar en el código fuente?"

Nadie respalda clústeres por capricho. El propósito es la rapidez, el control y la capacidad de supervivencia ante una avería. Si alguna vez has afrontado un clúster caído a mitad de una actualización o un error de configuración de seguridad que afectó a producción, sabes bien lo que vale disponer de un punto limpio de recuperación.

¿Pero qué pasa con GitOps?

Otra objeción frecuente suele ser: "Nosotros hacemos GitOps. Simplemente redesplegamos todo."

En la teoría suena perfecto. Sin embargo, en el mundo real GitOps no siempre es tan ordenado. El estado del clúster, la lógica de los pipelines y ciertos secretos volátiles a menudo existen fuera del control de versiones; ante un desastre, desplegar todo desde cero suele resultar más lento y arriesgado que restaurar una infraestructura previamente validada.

Como señalaba otro usuario: "Restaurar un backup es más rápido que desplegar IaC desde decenas o cientos de repositorios."

Con plataformas como Argo CD, precargar el estado del clúster y dejar que el mecanismo de conciliación sincronice los cambios pendientes resulta infinitamente más fluido que reconstruir el universo entero desde la nada.

Inmutable, cifrado y con redundancia regional

La comodidad operativa es solo una parte de la ventaja. El tratamiento de estos snapshots en AWS Backup incorpora prestaciones de categoría empresarial:

• Backups inmutables para blindarse frente a borrados accidentales o maliciosos
• Copias entre cuentas y entre distintas regiones de AWS
• Integración con almacenes de backup (backup vaults) para control de accesos y directivas
• Soporte de cifrado en reposo mediante AWS KMS

De este modo, tus copias de seguridad de EKS pueden alinearse con el mismo marco de seguridad y cumplimiento normativo que ya exiges para RDS o EC2, sin necesidad de reinventar la rueda.

El veredicto hasta ahora

Este lanzamiento supone un gran acierto tanto para AWS como para cualquier usuario de Kubernetes que afronte complejidades reales, dinámicas de equipo imperfectas e incidentes impredecibles.

La comunidad valora especialmente su sencillez, ya que encaja de forma natural en los flujos de trabajo consolidados de AWS. Destacan la agilidad de levantar clústeres sin pelearse con plantillas de Helm, código de Terraform ni parches provisionales; la flexibilidad de recuperar clústeres completos, recursos parciales o volúmenes persistentes aislados, y la tranquilidad del cifrado con KMS y bóvedas con control estricto de acceso.

Por encima de todo, reduce fricción innecesaria, que es exactamente como debería funcionar el backup en la nube.

Conclusiones finales

Si tenías dudas sobre cómo enfocar tu estrategia de backup en EKS, ha llegado el momento de dar el paso. El soporte nativo en AWS Backup aporta consistencia, sencillez y solvencia técnica a un ámbito que tradicionalmente se resolvía con soluciones caseras o herramientas de terceros.

Para quienes ya operan de lleno en el ecosistema de AWS, adoptar esta integración es una decisión evidente. Y para quienes han batallado intentando imponer estándares de backup para Kubernetes en organizaciones grandes, puede ser la respuesta esperada.

La etapa de los scripts artesanales quedó atrás. La resiliencia de Kubernetes en AWS se apoya ahora en la escala, la fiabilidad y la simplicidad a golpe de clic, y el backup nativo se consolida como el nuevo estándar.