Amazon web services AWS VPC子网方法

我是AWS建筑师。我最近访问了一个帐户，该帐户的应用程序目前正在集成到系统中，存在一些主要的设计缺陷

在我看来，子网太大了，一种“一刀切”的心态最终导致懒惰的安全小组向整个子网/24和/25甚至整个专有网络开放端口。此外，由于操作系统中的静态IP地址变硬，一些应用程序被配置到错误的子网，需要很长的前置时间才能再次移动它们，因此存在路由问题。我们根本无法将子网从公共更改为私有，因为其他应用程序驻留在那里。哎呀

我的问题

在规划50-150个服务器的SaaS开发、qa、stage、prod/Corporate Application network内部应用程序环境时，您对子网及其与安全组的关系有何看法

如果您有较大的子网，例如：/24 public，/24 private用于所有应用程序，您将需要使用连接到前端实例的安全组作为堆栈下一级安全组上的源地址，才能同时使用1只允许来自特定服务端口上特定源的流量2是自动缩放的候选对象，对吗？否则，您将需要管理单个IP作为源地址，以限制流量，这将是一个巨大的难题2无法自动缩放或通过打开来自整个子网/vpc的流量进行自动缩放，这是不安全的

我为较小子网设计的备选子网是：

具有较小的子网/27、/28、/26，并且只允许来自相应子网的流量：

Web层A/27 AZ-A 网络层B/27 AZ-E

应用层A/27 AZ-A 应用层B/27 AZ-E

应用层安全组仅允许来自使用Web层A/B CIDR作为源网络的Web层A和B的服务端口上的流量。这将允许通过安全组在子网之间自动缩放和控制流量。在这个模型中，我们不会在SGs中使用其他安全组作为源，可能会与负载平衡器一起使用

---

你们的问题是。。选择哪一个？我觉得后者更小，可以用作构建块，每个应用都有自己的子网层。。慢慢切出VPC馅饼。你是做什么的？在操作和可伸缩性方面有什么意义？

我也是一名AWS架构师，在我看来，如果你通过IP地址进行访问，那你就错了

有许多不同的方法来分离开发、测试、qa和产品环境，并且根据您的需求都是有效的。通过将不同的环境放在单独的AWS帐户中，可以完全隔离它们。您也可以考虑单独的VPCs，或者简单地在VPC中分离子网。使用单独的子网，您可以通过路由规则限制访问，还可以为每个环境创建单独的安全组集

安全组应授予对其他安全组的访问权限，而不是IP地址。假设您有一个web应用程序和一个数据库服务器。创建一个DBAccess组—它不必有任何规则—并将其分配给web实例。然后创建一个DBServer组，该组向在DBAccess组下运行的任何对象打开适当的DB端口。为了进一步限制访问，您需要创建DBAccess Prod、-QA、-Dev等。通过云形成来实现这一点使过程变得简单

---

顺便说一句，亚马逊发布了一个NIST 800-53参考体系结构，您可能想看看。

这不是一个编程问题，可能更适合ServerFault.com。