Hola comunidad,
Hoy quiero compartir con ustedes sobre un servicio muy interesante que de manera simplificada nos ayuda a garantizar la resiliencia y disponibilidad de nuestra información en la nube: AWS Backup.
Además de explicar sus conceptos básicos, estaré detallando cómo implementar una estrategia de copias de seguridad robusta: Cross-Account y Cross-Region que en español sencillo es crear copias de respaldo en una región distinta dentro de una cuenta distinta de donde está el repositorio de información.
¿Qué es AWS Backup?
AWS Backup es un servicio de copias de seguridad completamente administrado por AWS diseñado para proteger los datos de diferentes servicios que almacenan datos.
Anteriormente, administrar backups significaba crear scripts personalizados o usar configuraciones individuales por servicio (ej. instantáneas manuales para RDS, S3, DynamoDB, etc.). AWS Backup resuelve esto brindando un panel de control único donde puedes configurar políticas de respaldo que aplican de forma unificada a todos tus recursos compatibles.
Principales beneficios:
- Gestión centralizada: Un solo lugar para configurar, gestionar y auditar respaldos.
- Automatización basada en políticas: Define planes de respaldo (frecuencia, retención, ciclo de vida) que pueden ser asignados todos los recursos de un mismo tipo o específicos a través de reglas de etiquetado.
- Seguridad y Cumplimiento: Integración con AWS KMS para cifrado de respaldos y generación de reportes.
Estrategia Cross-Account y Cross-Region
Para cumplir con arquitecturas bien diseñadas y prácticas sólidas de Disaster Recovery (DR), es recomendable aislar algunas copias de seguridad adicional a las que creas en tu cuenta principal, y por ello implementamos una estrategia de respaldo en otra región y en otra cuenta.
- Cross-Region (Entre Regiones): Garantiza que, en el raro escenario de que una región completa de AWS esté indisponible, tus respaldos persistan en una región secundaria y estén listos para ser restaurados.
- Cross-Account (Entre Cuentas): Asegura que, si una cuenta sufre un compromiso de seguridad, los atacantes no puedan alterar o eliminar los respaldos que residen en una cuenta completamente distinta (cuenta de bóveda aislada).
Implementación Práctica
He preparado un repositorio público en GitHub donde puedes encontrar las plantillas de infraestructura como código para desplegar este escenario:
https://github.com/pangoro24/aws-backup-cross-account--cross-region-solution
El reto técnico: Evitando la Dependencia Circular
Al implementar soluciones cross-account con cifrado personalizado (KMS), surge un clásico dilema:
- La bóveda en la cuenta de Destino (DR) necesita que su llave KMS confíe en el rol de IAM de la cuenta de Origen (Main) para poder descifrar y copiar los datos.
- El plan de AWS Backup en la cuenta de Origen (Main) necesita conocer de antemano el ARN de la bóveda de Destino (DR) para poder configurar la regla de copia.
Si intentáramos desplegar todo en un solo bloque, fallaría debido a que cada recurso requiere que el otro exista primero.
La solución: Re-estructurar el despliegue de la cuenta de origen en dos plantillas independientes. Primero creamos el Rol de IAM (role-template.yaml), luego desplegamos la cuenta de DR, y finalmente desplegamos el resto de los recursos principales (el plan, la bóveda local y las llaves KMS).
Pasos a Alto Nivel para la Implementación:
- Configurar AWS Organizations: Debes habilitar el "Trusted Access" para AWS Backup en tu organización y permitir los respaldos "Cross-Account" en la configuración de AWS Backup.
- Desplegar el Rol de IAM (Cuenta de Origen): Creamos el rol de AWS Backup en la cuenta principal para que exista antes de configurar las políticas KMS en la cuenta de destino.
- Crear Bóveda (Vault) en la Cuenta DR (Destino): Desplegamos la bóveda y su llave KMS en la cuenta de Disaster Recovery, configurando la política de la llave para permitir que el rol de la cuenta principal interactúe con ella.
- Desplegar el Plan Principal (Cuenta de Origen): Configuramos las llaves KMS locales, la bóveda de origen y el plan de AWS Backup (con copias locales y reglas de replicación cruzada hacia la cuenta DR).
-
Desplegar Recursos con Etiquetas: Creamos nuestros recursos de datos (como un bucket S3 o una tabla DynamoDB) con la etiqueta
backup-required=yes. AWS Backup los detectará y protegerá automáticamente.
Te invito a revisar el archivo README.md dentro del repositorio para ver los comandos detallados de despliegue usando AWS CLI. Uno de los errores comunes es la asignación de permisos en las llaves de KMS. Si no se están creando las copias de seguridad, empieza por revisar CloudTrail y ver si hay acciones de Backup denegadas por falta de permisos.
Próximos pasos: puedes intentar restaurar los repositorios de información a partir de los respaldos creados y configurar el vault lock a conveniencia.
Costo
Luego de tener el demo activado por varias semanas y donde el bucket de s3 y la tabla de dynamodb solo tienen datos de prueba, realmente el costo lo verás en las llaves de kms así que podrán realizar varios respaldos y copias antes de que decidan eliminar la infraestructura. A medida que el tamaño de los repositorios de información sea más grande, entonces sí podrías ver gastos significativos en almacenamiento de las copias, las restauraciones y la transferencia de datos entre regiones. El detalle de los costos está acá: https://aws.amazon.com/es/backup/pricing/
Conclusión
La tranquilidad de saber que tus datos están seguros, respaldados y en otra cuenta dedicada no tiene precio. AWS Backup facilita drásticamente la configuración y el monitoreo de estas estrategias de recuperación ante desastres que antes requerían un esfuerzo inmenso de desarrollo personalizado.
¿Ya estás usando AWS Backup de forma centralizada en tu organización? ¡Déjame saber en los comentarios!
Gracias por leer.
Referencias:
Top comments (0)