在 AWS 之外掛載彈性文件系統 (EFS)
我有一台在 AWS 之外的伺服器。我希望能夠將 EFS 卷安裝到它，但我不確定這是否可能。
也許如果您創建一個 VPC，並通過 VPN 創建一個隧道？
有人知道這是否可能嗎？
重要更新：
2018 年 10 月，AWS 擴展了支持 EFS 的網路技術的功能，使其現在可以原生地跨託管 VPN 連接和跨區域 VPC 對等工作，而無需訴諸下文詳述的代理解決方法。
EFS 在 2016 年末通過 AWS Direct Connect 電路增加了對連接的支持。
https://aws.amazon.com/blogs/aws/amazon-efs-update-on-premises-access-via-direct-connect-vpc/
評論提出了一些有趣的問題，因為在我最初閱讀這個問題時，我可能假設我對 EFS 的熟悉程度比你可能更高。
所以，首先，有一點背景：
Elastic File System 中的“Elastic”主要是指儲存空間和吞吐量的自動擴展——而不是外部訪問的靈活性。
EFS 似乎對您可以儲存的數據量沒有任何有意義的限制。EFS 卷上任何單個文件的記錄最大大小為52,673,613,135,872 字節 (52 TiB)。大多數其他限制同樣慷慨。
EFS 在計費方式上特別“有彈性”。與 EBS 卷上的文件系統不同，EFS 上沒有預先分配空間，您只需按小時平均為儲存的內容付費。您的費用會根據您儲存的數量增加和減少（它們是“彈性的”）。當您刪除文件時，您將在一小時內停止為它們佔用的空間付費。如果您將 1 GB 儲存 750 小時（≅1 個月）然後將其刪除，或者如果您將 375 GB 儲存 2 小時然後將其刪除，您的每月賬單將是相同的… $ 0.30. This is of course quite different than EBS, which will happily bill you $ 37.50 用於儲存
0x00該月剩餘時間的 375 GB。S3 的儲存定價模式與 EFS 基本相同，刪除對像後立即停止計費，成本約為 EFS 成本的 1/10，但正如我和其他人多次提到的，S3 不是文件系統。像 s3fs-fuse 這樣的實用程序試圖提供一個“阻抗橋”，但是在嘗試處理不是真正的文件系統的東西時存在固有的困難（覆蓋的最終一致性並不是最不重要的）。因此，如果您需要一個真正的“文件系統”，並且它適用於需要共享訪問的應用程序，或者難以確定所需的儲存空間，或者您希望它按需擴展，那麼 EFS 可能會很有用。
而且，當您擁有 8.0 EiB 的可用空間時，它看起來很酷。
$ 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但是，使用最適合您的應用程序的儲存服務當然很重要。每個選項都有其有效的案例。EFS 可能是 AWS 提供的最專業的儲存解決方案，其案例範圍比 EBS 或 S3 更窄。
但是您可以從 VPC 外部使用它嗎？
官方回答是否定的：
不支持通過 VPC 私有連接機制（例如 VPN 連接、VPC 對等互連和 AWS Direct Connect）裝載文件系統。
— http://docs.aws.amazon.com/efs/latest/ug/limits.html
EFS 目前僅限於 EC2 Linux 訪問。在 VPC 中也是如此。更多功能將很快添加。您可以關注 AWS 發布的新功能公告。
— https://forums.aws.amazon.com/thread.jspa?messageID=732749
但是，實際答案是 Yes，即使這不是官方支持的配置。為了使它工作，需要一些特殊的步驟。
每個 EFS 文件系統都使用彈性網路介面 (ENI) 在您的 VPC 中分配了端點 IP 地址，通常每個可用區一個，並且您希望確保將其安裝在與實例匹配的可用區中，不僅出於性能原因，而且還因為在跨可用區邊界傳輸數據時會產生頻寬費用。
這些 ENI 的有趣之處在於，它們似乎不使用它們所連接的子網的路由表。無論安全組設置如何，它們似乎都只能響應 VPC 內的實例（每個 EFS 文件系統都有自己的安全組來控制訪問）。
由於無法訪問外部路由，我無法直接通過我的硬體 VPN 訪問 EFS 端點……所以我求助於我的老朋友 HAProxy，這確實（正如 @Tim 預測的那樣）是完成這項工作所必需的。這是一個簡單的配置，因為 EFS 僅使用 TCP 埠 2049。
我在 t2.nano 上使用 HAProxy（HAProxy 非常高效），其配置如下所示：
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此伺服器位於 us-east-1b 中，因此它使用 us-east-1b 端點作為主要端點，如果 1b 中的端點未能通過健康檢查，則另外兩個用作備份。
如果您的 VPC 中有 VPN，則使用此代理實例的 IP 地址作為目標掛載卷（而不是直接使用 EFS 端點），瞧，您已經從 VPC 外部掛載了 EFS 文件系統。
我已經將它成功地安裝在外部 Ubuntu 機器以及 Solaris¹ 伺服器上（事實證明，EFS 非常方便，因為它可以更輕鬆地從它們那裡遷移服務來加速它們的退役）。
在某些情況下，例如將數據移動到 AWS 或在遷移期間在特定數據上並行執行舊系統和雲系統，EFS 似乎是贏家。
當然，具有較長往返時間的遺留系統的性能不會像 EC2 實例那樣好，但這是意料之中的——物理定律也不例外。儘管如此，EFS 和 HAProxy 網關似乎是使其在外部工作的穩定解決方案。
如果您沒有 VPN，那麼一對 HAProxy 機器，一個在 AWS 中，一個在您的數據中心，也可以通過 TLS 建立 EFS 隧道，與包裹在 TLS 中的有效負載建立單獨的 TCP 連接，以傳輸每個單獨的 EFS通過 Internet 連接。從技術上講，它不是 VPN，而是加密的連接隧道。這似乎也表現得很好。
¹Solaris 10 預設情況下（不足為奇）有些損壞——最初，root 似乎沒有特殊權限——由 root 創建的 EFS 卷上的文件歸 root 所有，但不能
chown從Solaris 機器 (Operation not permitted)，即使 Ubuntu 客戶端一切正常。在這種情況下，解決方案是使用svcadm disable svc:/network/nfs/mapid:default. 停止此服務會使一切按預期工作。此外，每次登錄時的呼叫/usr/sbin/quota都需要在/etc/profile. 可能有更好或更正確的解決方案，但它是 Solaris，所以我沒有足夠的好奇心去調查。