Almacenamiento de EC2: Instance Store frente a EBS

Las instancias EC2 pueden utilizar dos tipos de almacenamiento local: Instance Store y Amazon EBS (Elastic Block Store). Instance Store está conectado físicamente al servidor host y ofrece IOPS y rendimiento muy elevados, pero con una salvedad importante: los datos se pierden cuando la instancia se detiene o termina. EBS proporciona almacenamiento de bloques persistente conectado a la red, que sobrevive a la detención, el inicio y la terminación de la instancia. Comprender cuándo utilizar cada opción es un tema recurrente en el examen SAA-C03.

Instance Store (también denominado almacenamiento efímero) consta de SSD NVMe conectados físicamente al hardware host que ejecuta su instancia EC2. Los datos del instance store se pierden cada vez que la instancia se detiene, hiberna o termina, o si falla el hardware subyacente. Sin embargo, los datos se conservan después de un reinicio. Instance Store es ideal para datos de búfer, caché o trabajo temporal, archivos temporales y datos replicados en una flota (por ejemplo, nodos de Cassandra). No todos los tipos de instancia incluyen Instance Store; busque el sufijo d (por ejemplo, i3.xlarge, m5d.large).

Los volúmenes de Amazon EBS son almacenamiento conectado a la red que persiste de forma independiente del ciclo de vida de la instancia EC2. Un volumen EBS existe en una Availability Zone específica y puede asociarse a una instancia EC2 a la vez (excepto en el caso de io1/io2 multi-attach). Cuando detiene y reinicia una instancia, el volumen EBS conserva todos los datos. Puede separarlo de una instancia y asociarlo a otra en la misma AZ, o crear una instantánea para copiarlo a otra AZ o región.

AWS ofrece cuatro tipos de volúmenes EBS. gp3 (SSD de uso general): 3.000 IOPS y 125 MB/s de referencia, configurables de forma independiente hasta 16.000 IOPS y 1.000 MB/s; es la opción predeterminada y más rentable para la mayoría de las cargas de trabajo. gp2: SSD de uso general más antiguo, cuyos IOPS aumentan con el tamaño (3 IOPS/GB, máximo de 16.000); se está retirando en favor de gp3. io2 Block Express: SSD con IOPS provisionadas de hasta 256.000 IOPS y 4.000 MB/s, para bases de datos con un uso intensivo de E/S, como SAP HANA u Oracle. io1: SSD con IOPS provisionadas heredado.

Los dos tipos de EBS basados en HDD están optimizados para el rendimiento, no para los IOPS. st1 (HDD optimizado para rendimiento): 40 MB/s/TB de referencia, con ráfagas de hasta 250 MB/s/TB; es ideal para big data, el procesamiento de registros y los almacenes de datos con lecturas secuenciales grandes. sc1 (HDD en frío): 12 MB/s/TB de referencia, con ráfagas de hasta 80 MB/s/TB; es la opción de EBS de menor coste para datos secuenciales a los que se accede con poca frecuencia. Los volúmenes HDD no se pueden usar como volúmenes de arranque (dispositivo raíz). Elija st1 o sc1 únicamente cuando el rendimiento sea más importante que los IOPS y el patrón de acceso a los datos consista en lecturas o escrituras secuenciales grandes.

Los snapshots de EBS son copias de seguridad de un volumen en un momento dado que se almacenan de forma duradera en Amazon S3 (aunque se accede a ellos mediante la API de EC2, no directamente desde S3). Los snapshots son incrementales: el primero captura el volumen completo y los siguientes solo registran los bloques que cambiaron desde el snapshot anterior, lo que reduce el coste de almacenamiento. Puede crear un volumen EBS nuevo a partir de cualquier snapshot en cualquier AZ de la misma Region, o copiar el snapshot a otra Region para la recuperación ante desastres entre regiones.

Los volúmenes y snapshots de EBS se pueden cifrar mediante AWS KMS keys. El cifrado es transparente para la instancia: los datos se cifran en tránsito entre la instancia y el volumen, y en reposo en el almacenamiento. Puede habilitar el cifrado predeterminado a nivel de cuenta para que todos los volúmenes EBS nuevos creados en la cuenta se cifren automáticamente, sin tener que configurarlo por volumen. Para cifrar un volumen sin cifrar, debe crear un snapshot, crear una copia cifrada del snapshot y, a continuación, crear un volumen nuevo a partir del snapshot cifrado.

EBS Multi-Attach permite asociar un volumen io1 o io2 a un máximo de 16 instancias de EC2 en la misma Availability Zone de forma simultánea. Todas las instancias asociadas tienen acceso completo de lectura y escritura. Esta función se utiliza para aplicaciones Linux en clúster (como Oracle RAC o Teradata) que gestionan la concurrencia en la capa de aplicación mediante un sistema de archivos compatible con clústeres. Multi-Attach no sustituye a EFS para los sistemas de archivos compartidos; está diseñado específicamente para el acceso en bloque en clústeres con coordinación gestionada por la aplicación.

Criterios clave para decidir: ¿Necesita persistencia? → Use EBS. ¿Los datos se pueden volver a crear o están replicados? → Instance Store es una opción válida y ofrece un mayor rendimiento. ¿Se trata de una base de datos con datos críticos? → Use siempre EBS (con snapshots y cifrado). ¿Necesita espacio temporal de trabajo para el entrenamiento de ML o para operaciones de ordenación? → Use Instance Store para obtener el máximo rendimiento sin costes adicionales. En el examen suelen presentarse escenarios en los que debe determinar si el almacenamiento efímero o persistente es adecuado para una carga de trabajo concreta.

Las instancias optimizadas para EBS proporcionan un ancho de banda de red dedicado entre la instancia de EC2 y EBS, separado del ancho de banda de red general de la instancia. Esto evita la contención de red entre el tráfico de la aplicación y la E/S de almacenamiento. La mayoría de los tipos de instancias de generación actual están optimizados para EBS de forma predeterminada y sin coste adicional. Es posible que los tipos de instancias más antiguos requieran habilitar manualmente la optimización para EBS (con una tarifa horaria adicional). Para cargas de trabajo de bases de datos con un uso intensivo de E/S, confirme siempre que el tipo de instancia está optimizado para EBS para obtener todos los IOPS provisionados del volumen.

Amazon Data Lifecycle Manager (DLM) automatiza la creación, retención y eliminación de snapshots de EBS y AMIs. Puede definir políticas de ciclo de vida que especifiquen qué volúmenes se deben respaldar (por etiqueta), con qué frecuencia se deben crear snapshots (cada 1, 2, 3, 4, 6, 8 o 12 horas, o diariamente) y cuántos snapshots se deben conservar. DLM elimina la necesidad de crear scripts de copia de seguridad personalizados y se integra con CloudWatch para supervisar el estado de las políticas. Para los snapshots entre regiones, configure una política de copia en la misma definición de DLM.

Compruebe sus conocimientos sobre los conceptos de AWS Solutions Architect (SAA-C03) de esta lección.

En esta lección ha aprendido que: Instance Store ofrece el máximo rendimiento de E/S local, pero es efímero: los datos se pierden al detener o terminar la instancia; EBS proporciona almacenamiento persistente en bloques conectado por red, con cuatro tipos de volúmenes optimizados para IOPS (gp3, io2) o rendimiento (st1, sc1); y los snapshots de EBS permiten realizar copias de seguridad en un momento dado, almacenadas en S3, que se pueden usar para la recuperación entre AZ o entre regiones. A continuación, exploraremos los fundamentos del almacenamiento de objetos de S3.