我一直在与一个团队合作，该团队曾经将所有应用程序和 HTTP 服务（如Apache或Tomcat）安装到“/srv”目录。我怀疑主要是为了尽可能地将已安装的服务与操作系统分开。对于我自己的项目，我保留了这种做法。然而，随着时间的推移，它越来越看起来可能不是一个好主意：它阻止您使用特定于发行版的软件包（他们在那个团队中名声很差，所以大部分都是自定义安装），我注意到在尝试使用已经可用的厨师食谱时，我遇到了一些麻烦。
所以最近我很想切换到使用特定于发行版的包，而不是尝试构建适合该目录结构的自定义安装。我想知道是否有任何我可能会忽略的东西。实际上是否有充分的理由将所有内容都放入“/srv”目录中，或者是否有充分的理由不使用特定于发行版的软件包？
我正在为一家几乎不会有很多流量的初创公司建立基础设施，但应该能够在需要时进行扩展。
我们倾向于使用 LB 设置，将流量分配到专用私有子网（超过 3 个可用区）中的前端节点，然后向它们自己专用子网上的受支持节点发出请求，然后请求到mongodb 通过 atlas 和 vpc 对等互连进行管理。
为了让每个节点进行配置，它都需要访问 Internet。后端节点也会向第三方服务发出请求，因此在运行时也需要访问互联网。
我看到三个选项：
为每个可用区中的每个私有子网设置一个 nat 网关。根据位置，这相当于每个可用区每个子网约 30 美元。有 3 个可用区和 2 个子网，每月总计约 180 美元，这实际上比我们计划用于 ec2 实例的要多，而系统上没有太多流量和负载。我们可能可以将其减少到只在每个可用区中为所有私有子网使用 1 个 nat 网关，但仍然约为 90 美元。
将 ec2 实例设置为 nat 网关，这可能会便宜一些，但需要维护和设置。
只需使用一个私有子网，为每个节点分配公共 ip，并通过路由表条目使用 Internet 网关。我认为使用专用的私有子网没有多大意义，因为节点无论如何都应该能够通过网关相互连接。
最后一个选项很可能是最便宜的选项，因为一个弹性 ip 已经包含在 ec2 实例中，并且不需要专用网关。但是，我想知道这样做是否存在重大不利因素或风险？我们计划在需要时（比如有大量流量）重新考虑使用专用子网的想法，但我们真的希望在开始时尽可能降低成本。