Actualizaciones importantes:
En octubre de 2018, AWS amplió las capacidades de la tecnología de red que respalda EFS para que ahora funcione de forma nativa en conexiones VPN administradas y emparejamiento de VPC entre regiones, sin recurrir a la solución proxy que se detalla a continuación.
https://aws.amazon.com/about-aws/whats-new/2018/10/amazon-efs-now-supports-aws-vpn-and-inter-region-vpc-peering/
EFS agregó soporte para conectividad a través de circuitos de AWS Direct Connect a fines de 2016.
https://aws.amazon.com/blogs/aws/amazon-efs-update-on-premises-access-via-direct-connect-vpc/
Los comentarios han planteado algunos problemas interesantes, ya que en mi lectura inicial de la pregunta, es posible que haya asumido más familiaridad con EFS que usted.
Entonces, primero, un poco de historia:
El "Elastic" en Elastic File System se refiere principalmente a la escala automática del espacio de almacenamiento y el rendimiento, no a la flexibilidad de acceso externo.
EFS no parece tener límites significativos en la cantidad de datos que puede almacenar. El tamaño máximo documentado de cualquier archivo individual en un volumen EFS es 52,673,613,135,872 bytes (52 TiB) . La mayoría de los otros límites son igualmente generosos.
EFS es particularmente "elástico" en la forma en que se factura. A diferencia de los sistemas de archivos en volúmenes EBS, el espacio no se asigna previamente en EFS, y solo paga por lo que almacena en promedio por hora. Sus cargas crecen y se reducen (son "elásticas") según la cantidad que haya almacenado. Cuando elimina archivos, deja de pagar por el espacio que ocuparon en una hora. Si almacena 1 GB durante 750 horas (≅1 mes) y luego lo elimina, o si almacena 375 GB durante 2 horas y luego lo elimina, su factura mensual sería la misma ... $ 0.30. Por supuesto, esto es bastante diferente de EBS, que felizmente le facturará $ 37.50 por almacenar 375 GB de 0x00las horas restantes del mes.
El modelo de precios de almacenamiento de S3 es muy similar al de EFS, ya que la facturación del almacenamiento se detiene tan pronto como elimina un objeto, y el costo es ~ 1/10 del costo de EFS, pero como yo y otros hemos mencionado muchas veces, S3 no es un sistema de archivos Las utilidades como s3fs-fuse intentan proporcionar un "puente de impedancia", pero existen dificultades inherentes al tratar de tratar algo que no es realmente un sistema de archivos como si lo fuera (la consistencia eventual para sobrescribir no es la menor de ellas). Por lo tanto, si lo que necesita es un "sistema de archivos" real, y es para una aplicación donde el acceso necesita ser compartido, o el almacenamiento necesita espacio requerido es difícil de determinar o si desea escalar a pedido, EFS puede ser útil.
Y se ve genial cuando tienes 8.0 EiB de espacio libre.
$ df -h | egrep '^Filesystem|efs'
Filesystem Size Used Avail Use% Mounted on
us-west-2a.fs-5ca1ab1e.efs.us-west-2.amazonaws.com:/ 8.0E 121G 8.0E 1% /srv/efs/fs-5ca1ab1e
us-west-2a.fs-acce55ed.efs.us-west-2.amazonaws.com:/ 8.0E 7.2G 8.0E 1% /srv/efs/fs-acce55ed
Pero, por supuesto, es importante utilizar el servicio de almacenamiento más apropiado para sus aplicaciones. Cada una de las opciones tiene sus casos de uso válidos. EFS es probablemente la más especializada de las soluciones de almacenamiento ofrecidas por AWS, ya que tiene un conjunto de casos de uso más limitado que EBS o S3.
¿Pero puedes usarlo desde fuera de la VPC?
La respuesta oficial es No :
No se admite el montaje de un sistema de archivos a través de mecanismos de conectividad privada VPC, como una conexión VPN, emparejamiento VPC y AWS Direct Connect.
- http://docs.aws.amazon.com/efs/latest/ug/limits.html
Actualmente, EFS está limitado solo a acceso EC2 Linux. Eso también dentro de la VPC. Más características se agregarán pronto. Puede estar atento a los anuncios de AWS para las nuevas funciones lanzadas.
- https://forums.aws.amazon.com/thread.jspa?messageID=732749
Sin embargo, la respuesta práctica es Sí , a pesar de que esta no es una configuración oficialmente compatible. Para que funcione, se requieren algunos pasos especiales.
A cada sistema de archivos EFS se le asignan direcciones IP de punto final en su VPC utilizando interfaces de red elásticas (ENI), generalmente una por zona de disponibilidad, y desea asegurarse de montar la que está en la zona de disponibilidad que coincida con la instancia, no solo por razones de rendimiento, sino también también porque se aplican cargos por ancho de banda al transportar datos a través de los límites de la zona de disponibilidad.
Lo interesante de estas ENI es que no parecen usar las tablas de ruta para las subredes a las que están conectadas. Parecen poder responder solo a instancias dentro de la VPC, independientemente de la configuración del grupo de seguridad (cada sistema de archivos EFS tiene su propio grupo de seguridad para controlar el acceso).
Dado que no hay rutas externas accesibles, no puedo acceder a los puntos finales EFS directamente a través de mi VPN de hardware ... así que recurrí a mi viejo amigo HAProxy, que de hecho (como predijo @Tim) es necesario para que esto funcione. Es una configuración sencilla, ya que EFS usa solo el puerto TCP 2049.
Estoy usando HAProxy en un t2.nano (HAProxy es muy eficiente), con una configuración que se parece a esto:
listen fs-8d06f00d-us-east-1
bind :2049
mode tcp
option tcplog
timeout tunnel 300000
server fs-8d06f00d-us-east-1b us-east-1b.fs-8d06f00d.efs.us-east-1.amazonaws.com:2049 check inter 60000 fastinter 15000 downinter 5000
server fs-8d06f00d-us-east-1c us-east-1c.fs-8d06f00d.efs.us-east-1.amazonaws.com:2049 check inter 60000 fastinter 15000 downinter 5000 backup
server fs-8d06f00d-us-east-1d us-east-1d.fs-8d06f00d.efs.us-east-1.amazonaws.com:2049 check inter 60000 fastinter 15000 downinter 5000 backup
Este servidor está en us-east-1b, por lo que utiliza el punto final us-east-1b como primario, los otros dos como copias de seguridad si el punto final en 1b falla alguna vez en una comprobación de estado.
Si tienes una VPN en tu VPC, entonces montas el volumen usando la dirección IP de esta instancia de proxy como objetivo (en lugar de usar el punto final EFS directamente), y voilà has montado el sistema de archivos EFS desde fuera de la VPC.
Lo he montado con éxito en máquinas Ubuntu externas, así como en servidores Solaris® (donde EFS ha demostrado ser muy útil para acelerar su desmantelamiento al facilitar la migración de servicios fuera de ellos).
Para ciertas situaciones, como mover datos a AWS o ejecutar sistemas heredados y en la nube en paralelo sobre datos específicos durante una migración, EFS parece ser un ganador.
Por supuesto, los sistemas heredados, que tienen tiempos de ida y vuelta más altos, no funcionarán tan bien como las instancias de EC2, pero eso es de esperar: no hay excepciones a las leyes de la física. A pesar de eso, EFS y la puerta de enlace HAProxy parecen ser una solución estable para que funcione externamente.
Si no tiene una VPN, un par de máquinas HAProxy, una en AWS y otra en su centro de datos, también pueden hacer un túnel de EFS sobre TLS, estableciendo una conexión TCP individual con la carga útil envuelta en TLS para el transporte de cada EFS individual conexión a través de Internet. Técnicamente no es una VPN, sino un túnel cifrado de conexiones. Esto también parece funcionar bastante bien.
OSolaris 10 está (no sorprendentemente) algo roto de forma predeterminada: inicialmente, la raíz no parecía tener privilegios especiales; los archivos en el volumen EFS creado por la raíz son propiedad de la raíz, pero no pueden ser chowneditados a otro usuario desde Máquina Solaris ( Operation not permitted), aunque todo funciona como se espera de los clientes de Ubuntu. La solución, en este caso, es derrotar al demonio de mapeo de ID NFS en la máquina Solaris svcadm disable svc:/network/nfs/mapid:default. Detener este servicio hace que todo funcione como se esperaba. Además, la invocación de /usr/sbin/quotaen cada inicio de sesión debe deshabilitarse /etc/profile. Puede haber soluciones mejores o más correctas, pero es Solaris, por lo que no tengo la curiosidad de investigar.