Snapshots, cifrado y RAID de EBS

Los snapshots de EBS son copias de seguridad de volúmenes EBS en un momento dado, almacenadas de forma duradera en Amazon S3 (aunque los gestiona EBS y no se puede acceder a ellos directamente desde la consola de S3). El primer snapshot es una copia completa; los siguientes son incrementales: solo se almacenan los bloques que han cambiado desde el último snapshot. Aunque el almacenamiento sea incremental, puede restaurar cualquier snapshot individual en un volumen completo. Los snapshots son el mecanismo principal para realizar copias de seguridad, migraciones y recuperación ante desastres de volúmenes EBS.

Se le factura por el almacenamiento real utilizado por los bloques incrementales de los snapshots de todos los snapshots de un volumen, no por el tamaño del volumen. Si elimina snapshots intermedios, S3 consolida los datos para que los snapshots restantes sigan representando puntos de restauración completos. Para gestionar los costes a escala, utilice Amazon Data Lifecycle Manager (DLM) para crear programaciones de snapshots y políticas de retención; por ejemplo, tome snapshots diarios, conserve los últimos 7 diarios, 4 semanales y 12 mensuales, y elimine automáticamente los más antiguos.

Los snapshots se pueden copiar entre regiones para la recuperación ante desastres y la distribución geográfica. También puede compartir snapshots con cuentas de AWS específicas (o hacerlos públicos) para transferir datos de EBS entre cuentas sin utilizar la red. Al copiar un snapshot, puede cambiar la clave de cifrado; así puede mover datos de un volumen sin cifrar a uno cifrado, o de una clave de una cuenta a una clave de otra.

Crear un volumen a partir de un snapshot es sencillo, pero hay que tener en cuenta el rendimiento: los volúmenes restaurados a partir de snapshots comienzan con todos los bloques almacenados en S3 y se cargan de forma diferida en el primer acceso. Esto puede provocar una mayor latencia para los bloques que todavía no se hayan cargado en el volumen. Para bases de datos de producción, utilice Fast Snapshot Restore (FSR), una función de pago que precalienta el snapshot para que los volúmenes alcancen inmediatamente el rendimiento máximo. Como alternativa, puede precalentar el volumen leyendo todos los bloques con dd o fio después de la restauración.

El cifrado de EBS utiliza AES-256 para cifrar los datos en reposo (en el volumen), en tránsito entre el volumen y la instancia EC2, y en los snapshots. El hipervisor de EC2 gestiona el cifrado de forma transparente, por lo que la aplicación no percibe ninguna diferencia. El cifrado utiliza claves de AWS KMS: puede utilizar la clave administrada por AWS (aws/ebs) o una clave administrada por el cliente (CMK). Una vez cifrado un volumen, también se cifran todos los datos escritos en él y todos los snapshots creados a partir de él.

No puede cifrar directamente un volumen EBS existente sin cifrar. La solución consiste en un proceso de varios pasos: (1) crear un snapshot del volumen sin cifrar, (2) copiar el snapshot con --encrypted para crear un snapshot cifrado, (3) crear un volumen cifrado nuevo a partir del snapshot cifrado, (4) detener la instancia, separar el volumen antiguo, asociar el nuevo volumen cifrado y reiniciar. Este proceso se puede automatizar mediante scripts y aparece en el examen SAA-C03 como un escenario de migración.

RAID 0 (distribución) reparte los datos entre varios volúmenes EBS para agregar sus IOPS y throughput. Dos volúmenes gp3 de 16.000 IOPS en RAID 0 proporcionan aproximadamente 32.000 IOPS. La desventaja es que, si falla cualquiera de los volúmenes, se pierden todos los datos: no existe redundancia. RAID 0 es adecuado para datos temporales o fáciles de recrear en los que la prioridad es el throughput máximo, como capas de caché, colas de procesamiento o espacio de trabajo temporal. Los snapshots de toda la matriz RAID requieren coordinar la coherencia.

RAID 1 (duplicación) escribe datos idénticos simultáneamente en dos volúmenes EBS. Si falla un volumen, el otro contiene una copia completa. RAID 1 proporciona la redundancia de dos volúmenes con la capacidad de uno solo. Sin embargo, en los volúmenes EBS esto suele ser redundante debido a la replicación integrada de EBS a nivel de AZ. AWS recomienda utilizar arquitecturas EBS Multi-AZ (mediante Multi-AZ RDS o un ASG entre AZ) en lugar de RAID 1 en EBS, ya que EBS ya replica los datos dentro de una AZ. RAID 1 en EBS es poco habitual en las arquitecturas modernas.

Una Amazon Machine Image (AMI) es una plantilla para lanzar instancias EC2 y está respaldada por uno o más snapshots de EBS: un snapshot por cada volumen incluido en la AMI (normalmente uno para el volumen raíz). Cuando crea una AMI personalizada a partir de una instancia en ejecución, AWS detiene la instancia (o utiliza VSS en Windows), toma snapshots de todos los volúmenes EBS asociados y registra la asignación en la AMI. Anular el registro de una AMI no elimina automáticamente sus snapshots de respaldo; debe eliminar los snapshots por separado para dejar de pagar por ellos.

Prácticas recomendadas para snapshots en cargas de trabajo de producción: congele o ponga en estado quiescente el sistema de archivos antes de crear snapshots de bases de datos para garantizar la coherencia (la mayoría de las bases de datos administradas, como RDS, lo hace automáticamente). Añada etiquetas a los snapshots con el entorno, el ID del volumen y la fecha para facilitar la gestión del ciclo de vida y la asignación de costes. Pruebe periódicamente los procedimientos de restauración: un snapshot que nunca se ha restaurado no es una copia de seguridad. Almacene copias entre regiones para la recuperación ante desastres. Utilice AWS Backup para gestionar de forma centralizada las políticas de EBS, RDS, DynamoDB y otros servicios.

EBS Snapshot Recycle Bin protege frente a la eliminación accidental de snapshots y AMI. Cuando se habilita con una regla de retención, los snapshots eliminados se trasladan a Recycle Bin en lugar de destruirse permanentemente. Puede recuperarlos durante el periodo de retención (de 1 día a 1 año). Esto es especialmente importante en escenarios de cumplimiento en los que debe poder recuperarse de la eliminación accidental por parte de un administrador o de un script de automatización descontrolado sin restaurar desde un nivel de copias de seguridad más antiguo.

Compruebe su comprensión de los conceptos de AWS Solutions Architect (SAA-C03) de esta lección.

En esta lección ha aprendido que los snapshots de EBS son incrementales y se almacenan en S3, con DLM para la gestión automatizada del ciclo de vida; que el cifrado requiere un flujo de trabajo de copia de snapshots para convertir volúmenes sin cifrar; y que RAID 0 distribuye los volúmenes para agregar el rendimiento, mientras que RAID 1 los duplica para proporcionar redundancia (aunque EBS ya replica los datos dentro de una AZ). A continuación exploraremos EFS para el almacenamiento de archivos Linux compartido.