EBS vs EFS para Múltiples Instancias EC2: Cómo Compartir Carpetas entre Servidores

Cuando intentas montar el mismo volumen EBS en cinco instancias EC2 simultáneamente y te preguntas por qué solo una instancia puede escribir, estás enfrentando una de las confusiones más comunes en arquitecturas AWS: la diferencia fundamental entre almacenamiento de bloque y almacenamiento de archivos compartido. La respuesta corta es que EBS no fue diseñado para esto, y EFS sí.

TL;DR: EBS vs EFS para Compartir Archivos entre Instancias EC2

Característica EBS (Elastic Block Store) EFS (Elastic File System)
Acceso simultáneo multi-instancia Limitado (solo con io1/io2 Multi-Attach, misma AZ) Sí, nativo — múltiples instancias, múltiples AZs
Protocolo Bloque (como un disco local) NFS v4.1/4.0
Caso de uso principal Base de datos, sistema operativo, disco raíz Contenido compartido, logs centralizados, home directories
Escalado de capacidad Manual (modificar volumen) Automático y elástico
Alcance geográfico Una sola AZ (excepto io1/io2 Multi-Attach) Regional (múltiples AZs)
Precio base Por GB aprovisionado Por GB almacenado (varía según clase de almacenamiento)

Precios y límites exactos varían — consulta siempre la documentación oficial de AWS.

Cómo Funciona EBS: Por Qué No Sirve para Compartir entre Instancias

EBS es almacenamiento de bloque. Piénsalo como un disco duro físico conectado directamente a un servidor: el sistema operativo lo ve como un dispositivo de bloque (/dev/xvdf, por ejemplo), lo formatea con un sistema de archivos (ext4, xfs), y lo monta. Ese sistema de archivos no tiene ningún mecanismo de coordinación para múltiples escritores simultáneos.

Es como conectar el mismo disco duro con un cable USB a cinco computadoras al mismo tiempo — el hardware no tiene forma de coordinar quién escribe qué, y el sistema de archivos se corrompe.

Existe una excepción documentada: los tipos de volumen io1 e io2 soportan la característica Multi-Attach, que permite adjuntar un volumen a hasta 16 instancias Nitro simultáneamente. Sin embargo, esta funcionalidad tiene restricciones críticas que la hacen inadecuada para el caso de uso de 'carpeta compartida':

  • Todas las instancias deben estar en la misma Zona de Disponibilidad.
  • El sistema de archivos montado debe ser un cluster-aware file system (como GFS2). Un ext4 o xfs estándar se corromperá con múltiples escritores.
  • La aplicación debe gestionar explícitamente la concurrencia de I/O.

Para compartir una carpeta de forma transparente entre cinco instancias EC2 sin gestionar locking a nivel de aplicación, Multi-Attach no es la solución correcta.

graph TD subgraph EBS_Estandar ["EBS Estándar — Una instancia"] V1["Volumen EBS"] I1["EC2 Instancia 1
(lectura/escritura)"] I2["EC2 Instancia 2
(sin acceso)"] I3["EC2 Instancia 3
(sin acceso)"] V1 --> I1 V1 -. "No adjuntado" .- I2 V1 -. "No adjuntado" .- I3 end subgraph EBS_MA ["EBS Multi-Attach — io1/io2, misma AZ"] V2["Volumen io2"] I4["EC2 Instancia A
(cluster-aware FS requerido)"] I5["EC2 Instancia B
(cluster-aware FS requerido)"] V2 --> I4 V2 --> I5 end subgraph EFS_Shared ["EFS — Acceso multi-instancia, multi-AZ"] FS["Sistema de Archivos EFS"] MT1["Mount Target AZ-1"] MT2["Mount Target AZ-2"] I6["EC2 us-east-1a"] I7["EC2 us-east-1a"] I8["EC2 us-east-1b"] FS --> MT1 FS --> MT2 MT1 --> I6 MT1 --> I7 MT2 --> I8 end
  1. EBS estándar: Un volumen adjunto a una sola instancia. Las demás no tienen acceso.
  2. EBS Multi-Attach (io1/io2): Múltiples instancias en la misma AZ pueden adjuntar el volumen, pero requiere cluster-aware file system — no es una carpeta compartida transparente.
  3. EFS: Un sistema de archivos NFS gestionado al que cualquier instancia con permisos puede montar simultáneamente, desde cualquier AZ dentro de la región.

EFS: Almacenamiento de Archivos Compartido para Múltiples Instancias EC2

Amazon EFS implementa el protocolo NFS v4.1. Cuando montas EFS en una instancia EC2, el kernel de Linux ve un sistema de archivos POSIX estándar — puedes hacer ls, cp, chmod, exactamente igual que con un directorio local. La diferencia es que ese mismo punto de montaje puede estar activo en cientos de instancias simultáneamente, con EFS gestionando la consistencia y el locking a nivel de servicio.

EFS crea mount targets (puntos de montaje de red) en cada subred/AZ donde quieras acceso. Las instancias se conectan al mount target de su AZ, lo que mantiene el tráfico de red dentro de la misma zona y reduce latencia.

graph LR EFS["Amazon EFS
(Sistema de Archivos Regional)"] MT1["Mount Target
us-east-1a
10.0.1.x:2049"] MT2["Mount Target
us-east-1b
10.0.2.x:2049"] I1["EC2 Instancia 1
us-east-1a"] I2["EC2 Instancia 2
us-east-1a"] I3["EC2 Instancia 3
us-east-1a"] I4["EC2 Instancia 4
us-east-1b"] I5["EC2 Instancia 5
us-east-1b"] EFS --> MT1 EFS --> MT2 MT1 --> I1 MT1 --> I2 MT1 --> I3 MT2 --> I4 MT2 --> I5
  1. El sistema de archivos EFS existe a nivel regional.
  2. EFS crea un Mount Target con una IP privada en cada subred configurada.
  3. Las instancias EC2 en cada AZ montan el sistema de archivos apuntando al mount target de su subred.
  4. Todas las instancias ven el mismo árbol de directorios y archivos, con consistencia garantizada por EFS.

Implementación Paso a Paso: Compartir una Carpeta con EFS entre Cinco Instancias

Paso 1: Crear el Sistema de Archivos EFS

Antes de crear el sistema de archivos, necesitas decidir el modo de rendimiento y la clase de almacenamiento. Para la mayoría de los casos de uso de carpetas compartidas con acceso concurrente, el modo de rendimiento General Purpose es el punto de partida correcto. El modo Bursting Throughput es el predeterminado y escala con el tamaño del sistema de archivos.

# Crear sistema de archivos EFS con cifrado en reposo habilitado
aws efs create-file-system \
  --performance-mode generalPurpose \
  --throughput-mode bursting \
  --encrypted \
  --tags Key=Name,Value=shared-folder-efs \
  --region us-east-1

Anota el FileSystemId del output (formato: fs-XXXXXXXX). Lo necesitarás en los pasos siguientes.

Paso 2: Crear un Security Group para EFS

EFS usa NFS sobre el puerto TCP 2049. Necesitas un Security Group que permita tráfico NFS desde las instancias EC2. Lo más limpio es referenciar el Security Group de las instancias EC2 como fuente, en lugar de usar rangos CIDR — así el acceso queda acotado exactamente a esas instancias.

# Crear Security Group para los mount targets de EFS
aws ec2 create-security-group \
  --group-name efs-mount-sg \
  --description 'Security group para mount targets EFS' \
  --vpc-id vpc-XXXXXXXXXXXXXXXXX \
  --region us-east-1

# Agregar regla de entrada: NFS desde el SG de las instancias EC2
aws ec2 authorize-security-group-ingress \
  --group-id sg-XXXXXXXXXXXXXXXXX \
  --protocol tcp \
  --port 2049 \
  --source-group sg-YYYYYYYYYYYYYYYYY \
  --region us-east-1

Reemplaza sg-XXXXXXXXXXXXXXXXX con el ID del SG recién creado para EFS, y sg-YYYYYYYYYYYYYYYYY con el Security Group de tus instancias EC2.

Paso 3: Crear Mount Targets en Cada Subred

Crea un mount target por cada subred donde tengas instancias EC2. Si tus cinco instancias están distribuidas en dos AZs, necesitas dos mount targets. Si todas están en la misma AZ, uno es suficiente — aunque distribuirlas en múltiples AZs es la práctica recomendada para alta disponibilidad.

# Mount target en subred de us-east-1a
aws efs create-mount-target \
  --file-system-id fs-XXXXXXXX \
  --subnet-id subnet-XXXXXXXXXXXXXXXXX \
  --security-groups sg-XXXXXXXXXXXXXXXXX \
  --region us-east-1

# Mount target en subred de us-east-1b (si tienes instancias en otra AZ)
aws efs create-mount-target \
  --file-system-id fs-XXXXXXXX \
  --subnet-id subnet-YYYYYYYYYYYYYYYYY \
  --security-groups sg-XXXXXXXXXXXXXXXXX \
  --region us-east-1

Paso 4: Configurar IAM — EFS Resource Policy y Permisos de Instancia

EFS soporta dos capas de control de acceso: el Security Group (red) y las políticas de recursos EFS con IAM (identidad). Para producción, lo correcto es usar ambas. La política de recursos EFS puede requerir que el cliente use TLS y autenticación IAM al montar.

Las instancias EC2 necesitan permisos IAM para llamar a las APIs de EFS si usas autenticación IAM al montar. El rol de instancia debe incluir al menos:

🔽 Ver política IAM para acceso EFS desde instancias EC2
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "EFSMountAccess",
      "Effect": "Allow",
      "Action": [
        "elasticfilesystem:ClientMount",
        "elasticfilesystem:ClientWrite",
        "elasticfilesystem:DescribeMountTargets"
      ],
      "Resource": "arn:aws:elasticfilesystem:us-east-1:123456789012:file-system/fs-XXXXXXXX"
    }
  ]
}

Si solo necesitas acceso de lectura desde algunas instancias, omite elasticfilesystem:ClientWrite en esos roles — el principio de mínimo privilegio aplica aquí directamente.

Paso 5: Montar EFS en las Instancias EC2

AWS proporciona el amazon-efs-utils, un paquete que simplifica el montaje y habilita cifrado en tránsito mediante TLS. Es la forma recomendada de montar EFS en instancias EC2 con Amazon Linux 2 o Amazon Linux 2023.

# Instalar amazon-efs-utils (Amazon Linux 2 / Amazon Linux 2023)
sudo yum install -y amazon-efs-utils

# Crear directorio de montaje
sudo mkdir -p /mnt/shared

# Montar EFS con TLS habilitado
sudo mount -t efs -o tls fs-XXXXXXXX:/ /mnt/shared

# Verificar montaje
df -h /mnt/shared

Repite este proceso en las cinco instancias. Una vez montado, todas verán el mismo contenido en /mnt/shared.

Paso 6: Montaje Persistente con /etc/fstab

Para que el montaje sobreviva reinicios de la instancia, agrega la entrada en /etc/fstab. Sin esto, tras un reinicio la instancia arranca sin el sistema de archivos montado — un error silencioso que solo aparece cuando la aplicación intenta acceder al directorio y encuentra que está vacío.

# Agregar a /etc/fstab en cada instancia
echo 'fs-XXXXXXXX:/ /mnt/shared efs _netdev,tls 0 0' | sudo tee -a /etc/fstab

# Verificar que fstab es correcto sin reiniciar
sudo mount -fav

La opción _netdev le indica al sistema que este dispositivo requiere red antes de montarse — crítico para que el orden de arranque sea correcto en EC2.

Diagnóstico: Problemas Comunes al Montar EFS

El error más frecuente que veo en producción no es de configuración de EFS — es un Security Group mal configurado. La instancia intenta conectar al mount target en el puerto 2049, el SG lo bloquea silenciosamente, y el comando mount simplemente se queda colgado hasta timeout. No hay un mensaje de error claro que diga 'puerto bloqueado'.

La secuencia de diagnóstico correcta:

Verificar conectividad de red al mount target

Antes de revisar configuración de EFS, confirma que la instancia puede alcanzar el mount target en el puerto correcto. Si este test falla, el problema está en Security Groups o routing — no en EFS.

# Obtener la IP del mount target
aws efs describe-mount-targets \
  --file-system-id fs-XXXXXXXX \
  --region us-east-1

# Desde la instancia EC2, probar conectividad TCP al puerto NFS
nc -zv  2049

Verificar estado del sistema de archivos y mount targets

Un mount target en estado creating o deleted no acepta conexiones. Confirma que todos están en estado available antes de intentar montar.

aws efs describe-mount-targets \
  --file-system-id fs-XXXXXXXX \
  --region us-east-1 \
  --query 'MountTargets[*].{AZ:AvailabilityZoneName,State:LifeCycleState,IP:IpAddress}'

Verificar permisos POSIX del directorio raíz

Un problema que sorprende a muchos: EFS crea el directorio raíz del sistema de archivos con permisos root:root 755. Si tus aplicaciones corren con un usuario distinto de root, no podrán escribir en el directorio raíz hasta que ajustes los permisos o uses un subdirectorio con los permisos correctos.

# Desde una instancia con el sistema de archivos montado
ls -la /mnt/shared

# Ajustar permisos si es necesario (como root)
sudo chown usuario-app:grupo-app /mnt/shared
sudo chmod 775 /mnt/shared

Cuándo EBS Multi-Attach Tiene Sentido (y Cuándo No)

Hay un patrón donde sí vale la pena considerar EBS Multi-Attach: aplicaciones de base de datos en cluster que ya implementan su propio locking distribuido — Oracle RAC es el ejemplo clásico. En ese contexto, la aplicación gestiona la concurrencia, y Multi-Attach proporciona el almacenamiento de bloque compartido de baja latencia que necesitan.

Para el caso de 'quiero que cinco instancias lean y escriban archivos en una carpeta compartida', EBS Multi-Attach no es la respuesta. La complejidad operativa de mantener un cluster-aware file system supera con creces los beneficios frente a EFS, que resuelve exactamente ese problema de forma gestionada.

graph TD START(["¿Necesito almacenamiento compartido
entre múltiples instancias EC2?"]) Q1{"¿La aplicación gestiona
locking de bloque
internamente?"} Q2{"¿Todas las instancias
están en la misma AZ?"} Q3{"¿Necesitas acceso
de archivos POSIX
estándar?"} EFS_REC["✅ Usa Amazon EFS
Solución recomendada"] EBS_MA["⚠️ EBS Multi-Attach io1/io2
+ cluster-aware FS
(alta complejidad operativa)"] EBS_STD["EBS Estándar
Una instancia por volumen"] START --> Q1 Q1 -- "Sí (ej: Oracle RAC)" --> Q2 Q1 -- "No" --> Q3 Q2 -- "Sí" --> EBS_MA Q2 -- "No" --> EFS_REC Q3 -- "Sí" --> EFS_REC Q3 -- "No, es un disco
de SO o BD estándar" --> EBS_STD
  1. Si necesitas compartir archivos entre múltiples instancias sin gestión de locking en la aplicación → EFS.
  2. Si tienes una base de datos o aplicación que ya gestiona concurrencia de bloque y necesitas baja latencia → evalúa EBS Multi-Attach con io1/io2 (misma AZ, cluster-aware FS).
  3. Si es un disco de sistema operativo o base de datos estándar → EBS estándar, una instancia por volumen.

Conclusión y Próximos Pasos con EFS para Múltiples Instancias EC2

Para compartir una carpeta entre cinco instancias EC2, EFS es la solución correcta. EBS no fue diseñado para acceso concurrente multi-instancia en el caso de uso general, y forzarlo con Multi-Attach introduce complejidad operativa significativa sin beneficios reales para este escenario.

Los próximos pasos recomendados después de implementar EFS:

  • Configura EFS Access Points si diferentes aplicaciones o usuarios necesitan vistas aisladas del sistema de archivos con permisos POSIX específicos.
  • Habilita EFS Intelligent-Tiering para mover automáticamente archivos poco accedidos a almacenamiento de menor costo.
  • Revisa las métricas de EFS en CloudWatch — especialmente BurstCreditBalance si usas modo Bursting, para anticipar degradación de rendimiento antes de que impacte producción.
  • Consulta la documentación oficial de Amazon EFS para configuraciones avanzadas de rendimiento y seguridad.

Glosario de Términos Clave

Término Definición
EBS (Elastic Block Store) Almacenamiento de bloque persistente para instancias EC2. Se comporta como un disco duro adjunto a una sola instancia (salvo Multi-Attach con io1/io2).
EFS (Elastic File System) Sistema de archivos NFS gestionado por AWS que permite acceso simultáneo desde múltiples instancias EC2 en una región.
Mount Target Punto de acceso de red que EFS crea en cada subred/AZ. Las instancias se conectan a este endpoint para montar el sistema de archivos.
Multi-Attach Característica de volúmenes EBS io1/io2 que permite adjuntar un volumen a múltiples instancias en la misma AZ. Requiere cluster-aware file system.
NFS (Network File System) Protocolo estándar de red para compartir sistemas de archivos. EFS implementa NFS v4.1 y v4.0.

Related Posts

Comentarios

Entradas populares de este blog

EC2 sin acceso a Internet en VPC personalizada: Internet Gateway y Route Table

Actualizar Contenido en CloudFront: Cómo Crear una Invalidación para Limpiar el Caché del Edge

Aumentar el Timeout de Lambda: Configuración, Límites y Diagnóstico en Producción