Patrones de integración de Amazon EFS con Lambda / ECS - Uso de sistemas de archivos compartidos en serverless

Se monta EFS en funciones Lambda y tareas de ECS para aprovechar un sistema de archivos compartido. Se presentan el diseño de los puntos de acceso y la optimización del rendimiento.

Unos 8 min de lecturaÚltima actualización: 2026-10-31

Integración de Lambda con EFS

Al montar EFS en una función Lambda, se puede acceder al sistema de archivos mediante una ruta bajo /mnt. El directorio /tmp de Lambda se puede configurar hasta 10 GB, y EFS es un sistema de archivos que crece y se reduce automáticamente según la carga de trabajo. Se puede usar para procesar modelos de machine learning de gran tamaño, conjuntos de datos y archivos temporales. En la configuración se especifican los ajustes de VPC de la función Lambda (subredes, grupos de seguridad) y el ID del sistema de archivos / ID del punto de acceso de EFS. Como la función Lambda se ejecuta dentro de una VPC, es necesario ubicarla en la misma subred que el destino de montaje de EFS o en una subred enrutable.

Diseño de puntos de acceso

Los puntos de acceso de EFS son una función que separa el acceso al sistema de archivos por aplicación. En cada punto de acceso se configura un directorio raíz (por ejemplo, /app1, /app2) y un usuario POSIX (UID/GID), y se asigna un punto de acceso distinto a cada función Lambda. Se puede separar de forma que la función A acceda solo a lo que hay bajo /app1 a través de /mnt/efs, y la función B solo a lo que hay bajo /app2. Al habilitar la autorización de IAM, se puede controlar el acceso basado en roles de IAM con la política del sistema de archivos de EFS, y se puede restringir el uso para que solo determinadas funciones Lambda puedan usar determinados puntos de acceso.

Integración con tareas de ECS y rendimiento

Se define un volumen de EFS en la definición de tarea de ECS y se especifica la ruta de montaje con mountPoints en la definición del contenedor. Varios contenedores de la misma tarea pueden compartir el mismo volumen de EFS, y esto se puede aprovechar en una configuración con el patrón sidecar en la que un contenedor de recopilación de logs lee los archivos de log del contenedor de la aplicación. Desde el punto de vista del rendimiento, el montaje de EFS añade una latencia de varios cientos de milisegundos durante el arranque en frío de Lambda. El impacto en la latencia se contiene evitando el arranque en frío de Lambda con Provisioned Concurrency o asegurando el throughput de EFS con el modo de throughput Elastic.

Consideraciones de precios de la integración con EFS

El precio de EFS se determina por la clase de almacenamiento y el modo de throughput. El almacenamiento Standard cuesta unos 0.30 USD por GB al mes, e IA (Infrequent Access), unos 0.016 USD (a fecha de agosto de 2026). Para acceder a EFS desde Lambda se conecta la función a una VPC, y una función nueva no se puede invocar hasta que la conexión esté preparada, lo que puede tardar unos minutos. Para el throughput de EFS se recomienda el modo Elastic, que escala automáticamente según los patrones de acceso. En los casos en que basta con el /tmp de Lambda (configurable hasta 10 GB, con cobro por la parte configurada por encima de 512 MB), se puede usar una configuración sin EFS.

Ampliación de los casos de uso

Al combinar EFS con serverless, se pueden ejecutar en Lambda y ECS procesos que manejan archivos. Si se coloca un modelo de machine learning grande en EFS y se comparte para cargarlo desde varias funciones Lambda, se puede ejecutar la inferencia sin estar limitado por el tamaño máximo del paquete de despliegue. También se puede usar para mantener un estado compartido en el que varias funciones y tareas consultan / actualizan los mismos archivos. También sirve como destino al migrar a contenedores, sin grandes reescrituras, aplicaciones existentes creadas sobre la base de un sistema de archivos. Se puede usar en cargas de trabajo centradas en operaciones con archivos, como los procesos que comparten temporalmente archivos intermedios de vídeo o de imagen.

Elección del modo de throughput

El rendimiento de EFS cambia según el modo de throughput que se elija. El modo que ajusta automáticamente el rendimiento según el volumen de acceso (Elastic) es adecuado para cargas de trabajo cuyas fluctuaciones de carga son difíciles de prever. Si se quiere asegurar un rendimiento constante, se elige el modo que asigna el throughput de antemano (Provisioned). Con el método tradicional, en el que el rendimiento se determina en proporción a la cantidad de datos almacenados, el rendimiento puede ser insuficiente cuando la capacidad es pequeña y el acceso es intenso, por lo que este punto requiere atención. Se elige un modo que equilibre la latencia y el coste según las características del acceso.

Disponibilidad y copias de seguridad

Los sistemas de archivos Regional de EFS almacenan los datos de forma redundante en varias zonas de disponibilidad, y los sistemas de archivos One Zone los almacenan en una sola zona. Si se prepara un destino de montaje en cada zona, se puede seguir accediendo desde otra zona aunque se produzca un fallo en una de ellas. Se combina esto con una configuración que distribuye Lambda y ECS en varias zonas para prepararse ante fallos de zona. Para prepararse ante eliminaciones accidentales y daños en los datos, se trabaja con un servicio de gestión de copias de seguridad para obtener copias periódicamente y se establece un sistema que permite restaurarlas cuando sea necesario. Para los datos cuya pérdida sería un problema, existe el método de prepararse ante desastres replicándolos en otra región.

Diseño de seguridad

Para usar un sistema de archivos compartido de forma segura, se diseña una protección en varias capas. Se protegen los datos habilitando el cifrado de los datos almacenados y cifrando también la ruta de comunicación. Se separan los permisos POSIX y los directorios raíz por punto de acceso para evitar el acceso que traspasa los límites entre aplicaciones. Además, si se usan la autorización de IAM y las políticas del sistema de archivos, se puede controlar que solo determinados roles puedan usar determinados puntos de acceso. Con el grupo de seguridad del destino de montaje, se permite la conexión solo desde las rutas autorizadas. Combinando todo esto, se crea una configuración que comparte el sistema de archivos con el mínimo privilegio.

Resumen

La integración de EFS con Lambda / ECS permite aprovechar un sistema de archivos compartido incluso en arquitecturas serverless. Con los puntos de acceso se pueden separar el directorio raíz y los permisos POSIX por aplicación, y usarlos para compartir datos entre funciones Lambda y para procesar archivos de gran tamaño. Con la gestión del ciclo de vida de Intelligent-Tiering, se pueden mover los archivos con poco acceso a IA y contener los costes de almacenamiento.

Referencias (recursos oficiales de AWS)

Las fuentes primarias de esta página son el sitio web y la documentación oficiales de AWS. Consulta las páginas oficiales siguientes para conocer las especificaciones y los precios más recientes.

Si esta página y la documentación oficial difieren, prevalece la documentación oficial.

Patrones de diseño de Amazon API Gateway - Criterios de selección entre REST API y HTTP APIClarificamos los criterios de selección entre HTTP API y REST API, y presentamos patrones de autenticación con Cognito y Lambda Authorizer, así como métodos prácticos de diseño de throttling.Por qué el límite de 15 minutos de Lambda es de 15 minutos - La racionalidad oculta en las restricciones de diseño serverlessSe explican los valores actuales de los diversos límites serverless, como el tiempo máximo de ejecución de 15 minutos de Lambda, el límite de memoria de 10 GB y el payload de 6 MB, y cómo afectan al diseño de la arquitectura. El análisis parte de la perspectiva de la operación multi-tenant y del ciclo de vida del entorno de ejecución.La verdad sobre el cold start de Lambda y cómo elegir entre 3 estrategias de optimizaciónExplicamos el mecanismo por el cual ocurre el cold start de Lambda desde el ciclo de vida de Firecracker MicroVM, y comparamos técnicas de optimización en 3 ejes: SnapStart, Provisioned Concurrency y diseño de funciones, en términos de costo y restricciones.Desarrollo serverless con AWS Lambda - Diseño de funciones y uso de event sourcesExplicamos el diseño de funciones de Lambda, el mapeo de event sources, las contramedidas para cold start y el uso de Powertools.Detrás de las 1.000 ejecuciones simultáneas de Lambda - Cómo funcionan el warm pool de Firecracker y el worker managerSe explica el mecanismo con el que Lambda gestiona las micro VM dentro del límite predeterminado de 1.000 ejecuciones simultáneas. También se presentan la estrategia de reutilización mediante el warm pool, las decisiones de ubicación del worker manager y las optimizaciones internas que reducen la tasa de cold start.Construcción de APIs serverless - Infraestructura API escalable con Amazon API GatewayExplicamos cómo construir APIs serverless utilizando Amazon API Gateway y Lambda.Diseño de máquinas de estado - Orquestación de flujos de trabajo con Step FunctionsSe explican los métodos de diseño de máquinas de estado que aprovechan AWS Step Functions y se presentan los flujos de trabajo visuales, la gestión de errores y la orquestación de flujos de trabajo mediante la integración con Lambda.Orquestación de flujos de trabajo diseñada con AWS Step Functions - Cómo elegir entre Standard y ExpressSe aclaran los criterios para elegir entre los flujos de trabajo Standard y los flujos de trabajo Express, y se presentan la gestión de errores declarativa con Retry/Catch y el procesamiento en paralelo a gran escala con el mapa distribuido.