Atualizações importantes:
Em outubro de 2018, a AWS expandiu os recursos da tecnologia de rede subjacente ao EFS, para que agora funcione de maneira nativa em conexões VPN gerenciadas e emparelhamento VPC entre regiões, sem recorrer à solução alternativa de proxy detalhada abaixo.
https://aws.amazon.com/about-aws/whats-new/2018/10/amazon-efs-now-supports-aws-vpn-and-inter-region-vpc-peering/
O EFS adicionou suporte à conectividade por meio dos circuitos do AWS Direct Connect no final de 2016.
https://aws.amazon.com/blogs/aws/amazon-efs-update-on-premises-access-via-direct-connect-vpc/
Os comentários levantaram algumas questões interessantes, pois na minha leitura inicial da pergunta, posso ter assumido mais familiaridade com o EFS do que você.
Então, primeiro, um pouco de fundo:
O "Elastic" no Elastic File System refere-se principalmente ao dimensionamento automático do espaço de armazenamento e da taxa de transferência - e não à flexibilidade de acesso externo.
O EFS não parece ter limites significativos na quantidade de dados que você pode armazenar. O tamanho máximo documentado de qualquer arquivo único em um volume EFS é de 52.673.613.135.872 bytes (52 TiB) . A maioria dos outros limites é igualmente generosa.
O EFS é particularmente "elástico" na forma como é cobrado. Ao contrário dos sistemas de arquivos nos volumes EBS, o espaço não é pré-alocado no EFS, e você paga apenas pelo que armazena em uma base horária. Suas cobranças aumentam e diminuem (são "elásticas") com base no valor armazenado. Ao excluir arquivos, você para de pagar pelo espaço que eles ocupavam dentro de uma hora. Se você armazenar 1 GB por 750 horas (± 1 mês) e depois excluí-lo, ou se você armazenar 375 GB por 2 horas e depois excluí-lo, sua fatura mensal será a mesma ... $ 0,30. Naturalmente, isso é bem diferente do EBS, que cobrará US $ 37,50 pelo armazenamento de 375 GB 0x00pelas horas restantes do mês.
O modelo de preços de armazenamento do S3 é o mesmo do EFS, pois a cobrança pelo armazenamento é interrompida assim que você exclui um objeto, e o custo é aproximadamente 1/10 do custo do EFS, mas como eu e outros já mencionamos várias vezes, o S3 não é um sistema de arquivo. Utilitários como o s3fs-fuse tentam fornecer uma "ponte de impedância", mas há dificuldades inerentes ao tentar tratar algo que não é realmente um sistema de arquivos como se fosse (a consistência eventual para substituições não é a menor delas). Portanto, se um "sistema de arquivos" real é o que você precisa, e é para um aplicativo em que o acesso precisa ser compartilhado, ou o espaço necessário para armazenamento é difícil de determinar ou você deseja que ele seja dimensionado sob demanda, o EFS pode ser útil.
E parece legal quando você tem 8,0 EiB de espaço livre.
$ 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
Mas é claro que é importante usar o serviço de armazenamento mais apropriado para seus aplicativos. Cada uma das opções possui seus casos de uso válidos. O EFS é provavelmente a mais especializada das soluções de armazenamento oferecidas pela AWS, com um conjunto de casos de uso mais restrito que o EBS ou S3.
Mas você pode usá-lo de fora da VPC?
A resposta oficial é Não :
A montagem de um sistema de arquivos por mecanismos de conectividade privada da VPC, como uma conexão VPN, emparelhamento VPC e AWS Direct Connect, não é suportada.
- http://docs.aws.amazon.com/efs/latest/ug/limits.html
No momento, o EFS está limitado apenas ao acesso ao EC2 Linux. Isso também dentro da VPC. Mais recursos serão adicionados em breve. Você pode acompanhar os anúncios da AWS para novos recursos lançados.
- https://forums.aws.amazon.com/thread.jspa?messageID=732749
No entanto, a resposta prática é Sim , mesmo que essa não seja uma configuração oficialmente suportada. Para fazê-lo funcionar, são necessárias etapas especiais.
Cada sistema de arquivos EFS recebe endereços IP de terminal em sua VPC usando interfaces de rede elástica (ENI), normalmente uma por zona de disponibilidade, e você deve garantir que monta aquele na zona de disponibilidade correspondente à instância, não apenas por motivos de desempenho, mas também porque tarifas de largura de banda se aplicam ao transportar dados através dos limites da zona de disponibilidade.
O interessante dessas ENIs é que elas não parecem usar as tabelas de rotas para as sub-redes às quais estão anexadas. Eles parecem capazes de responder apenas a instâncias dentro da VPC, independentemente das configurações do grupo de segurança (cada sistema de arquivos EFS tem seu próprio grupo de segurança para controlar o acesso).
Como nenhuma rota externa é acessível, não consigo acessar os pontos de extremidade do EFS diretamente na VPN do meu hardware ... então, virei para o meu velho amigo HAProxy, que de fato (como o @Tim previu) é necessário para fazer isso funcionar. É uma configuração simples, pois o EFS usa apenas a porta TCP 2049.
Estou usando o HAProxy em um t2.nano (o HAProxy é muito eficiente), com uma configuração que se parece com isso:
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
Esse servidor está em us-east-1b, portanto, usa o terminal us-east-1b como primário e os outros dois como backups se o terminal em 1b falhar em uma verificação de integridade.
Se você possui uma VPN em sua VPC, monta o volume usando o endereço IP dessa instância de proxy como destino (em vez de usar diretamente o terminal EFS) e pronto, você montou o sistema de arquivos EFS de fora da VPC.
Montei-o com sucesso em máquinas Ubuntu externas e em servidores Solaris® (onde o EFS se mostrou muito útil para acelerar o descomissionamento, facilitando a migração de serviços para longe deles).
Para certas situações, como mover dados para a AWS ou executar sistemas legados e de nuvem em paralelo em dados específicos durante uma migração, o EFS parece um vencedor.
Obviamente, os sistemas legados, com tempos de ida e volta mais altos, não terão um desempenho tão bom quanto as instâncias do EC2, mas isso é de se esperar - não há exceções às leis da física. Apesar disso, o EFS e o gateway HAProxy parecem ser uma solução estável para fazê-lo funcionar externamente.
Se você não possui uma VPN, um par de máquinas HAProxy, uma na AWS e outra no seu datacenter, também pode encapsular o EFS por TLS, estabelecendo uma conexão TCP individual com a carga útil envolvida no TLS para o transporte de cada EFS individual conexão pela Internet. Tecnicamente, não é uma VPN, mas encapsulamento criptografado de conexões. Isso também parece funcionar muito bem.
OlarO Solaris 10 é (não surpreendentemente) um pouco quebrado por padrão - inicialmente, o root não parecia ter privilégios especiais - os arquivos no volume EFS criado pelo root são de propriedade do root, mas não podem ser chowneditados para outro usuário do Máquina Solaris ( Operation not permitted), mesmo que tudo funcione conforme o esperado dos clientes Ubuntu. A solução, nesse caso, é derrotar o daemon de mapeamento de ID do NFS na máquina Solaris usando svcadm disable svc:/network/nfs/mapid:default. A interrupção desse serviço faz com que tudo funcione conforme o esperado. Além disso, a chamada de /usr/sbin/quotaem cada login precisa ser desativada /etc/profile. Pode haver soluções melhores ou mais corretas, mas é o Solaris, então não tenho curiosidade suficiente para investigar.