如果我有一个仅用于存储文件的 EC2 实例和另一个使用 apache 提供网页的 EC2 实例，我该如何让它们“链接”在一起？
答案1
您描述的情况（一台服务器运行 apache，另一台服务器存储文件）不提供任何真正的备份 - 可以说，它使故障的可能性加倍（您现在有两台机器，如果任何一台发生故障，整个系统将无法工作）。
如果您刚开始使用 EC2，那么获得类似功能的最简单方法是将您的数据存储在 EBS 驱动器上，并将您的自定义实例保存为 AMI。从那里，您可以设置自动扩展以始终维护 1 个实例 - 如果您的一个实例发生故障，则可以根据您的 AMI 将另一个实例联机，并且您可以使用快照（略微过时），或移动 EBS 卷以使一切恢复正常运行（可以自动化）。
如果您只是提供静态文件，那么您可以完全放弃 EC2，而直接使用 S3 - 它将提供您想要的可扩展性和（内部）冗余。但是，如果您正在使用数据库，那么将它们存储在 S3 上并不是一个好主意，因为它们会导致严重的性能损失。
如果您确实需要故障转移设置，那么即使一个实例发生故障，您也希望您的设置能够正常运行。如果有两个实例，则意味着要么 a) 每个实例都自给自足，要么 b) 当一个实例发生故障时，另一个等效实例将联机。
上述故障转移设置与自动缩放集群之间存在的潜在差异在于您拥有的控制程度。虽然 Cloudwatch（以及自动缩放）确实支持自定义指标，但其他解决方案在实施方面允许更多的灵活性。例如（纯理论），您可以设置一个 2 节点集群（例如在 Amazon 的 VPC 中）并使用 Heartbeat/Corosync 来监控每个实例的状态，使用 Pacemaker 管理资源（例如，如果您的 apache 失败而不是整个实例失败，则可以采取一些措施）。可以使用简单的 rsync（如果没有太多变化）或分布式文件系统（例如 Gluster）在实例之间共享文件。一个实例将被选为“领导者”，并且可以运行负载平衡器（例如 nginx、HAProxy 等）并向一个或另一个实例发送请求。这样的设计并非没有问题（并且肯定需要花费大量精力来设置），但可能会提供一些潜在架构的想法。
但是，要回答所问的问题（本质上相当于如何在本地访问远程文件）。您可以选择：
- 共享存储方法（文件存储在 S3 上，使用 fuse 在本地挂载）
- 网络文件系统（例如 Gluster - 可供网络实例访问的远程文件系统）
- 本地访问的远程文件系统（例如 sshfs - 基于 fuse 的方法通过 ssh/sftp 访问/挂载远程文件系统）
对于您选择的几乎任何方法，您都需要打开安全组上的端口以允许实例之间的通信 - 您可能希望将这些端口的访问限制为仅限同一安全组中的其他实例。