我是AWS架构师。我最近走进了一个帐户，该帐户存在一些主要的设计缺陷，目前正在将应用程序集成到系统中。
在我看来，子网太大了，只有一种尺寸适合所有心态，最终在懒惰的安全组中开放到整个子网（/ 24s和/ 25s）甚至整个VPC的端口。此外，由于操作系统中的静态IP地址增强，一些应用程序被配置到错误的子网并且需要很长的时间来再次移动它们，因此存在路由挑战。由于其他应用程序驻留在那里，我们根本无法将子网从公共更改为私有。 OY！
我的问题！
在规划50-150服务器SaaS（开发，qa，舞台，产品）/企业应用程序网络（内部应用程序）环境时，您对子网及其与安全组的关系有何看法？
如果您有大型子网（例如：/ 24 public，/ 24 private）用于所有应用程序，则需要使用连接到前层实例的安全组作为堆栈下方安全组的源地址能够同时1）只允许来自特定服务端口2）的特定源的流量成为自动缩放的候选者，对吧？否则，您需要管理单个IP作为源地址以限制流量，这将是1）巨大的痛苦2）无法自动缩放或通过打开来自整个子网/ vpc的流量进行自动扩展，这是不安全的。
我为小型子网设计的替代子网网络就是这个 -
拥有较小的子网（/ 27s，/ 28s，/ 26s）并且仅允许来自相应子网的流量：
Web Tier A（/ 27）（AZ-A） 网络层B（/ 27）（AZ-E）
App Aier A（/ 27）（AZ-A） App Tier B（/ 27）（AZ-E）
App Tier安全组仅允许来自Web Tiers A＆amp; A的服务端口上的流量。 B使用Web Tier A / B CIDR作为源网络。这将允许通过安全组在子网之间进行自动扩展和受控流量。在这个模型中，我们不会使用其他安全组作为我们的SG中的源，期望可能与负载平衡器一起使用。
问题是你选择哪一个？我觉得后者更小，它们可以用作构建块，每个应用程序都有自己的子网层......慢慢地雕刻出VPC饼。你是做什么？在操作和可扩展性方面有什么意义？
答案 0 :(得分：3)
我也是一名AWS架构师，在我看来，如果您通过IP地址进行访问，那么您做错了。
分离dev，test，qa和prod环境有许多不同的方法，并且所有方法都有效，具体取决于您的要求。您可以将不同的环境放在不同的AWS账户中，从而完全隔离它们。您还可以考虑单独的VPC，或者只是在VPC中分离子网。使用单独的子网，您可以通过路由规则限制访问，并为每个环境创建单独的安全组集。
安全组应授予对其他安全组的访问权限，而不是IP地址。所以假设您有一个Web应用程序和一个数据库服务器。创建一个“DBAccess”组 - 它不必具有任何规则 - 并将其分配给您的Web实例。然后创建一个“DBServer”组，为“DBAccess”组下运行的任何内容打开相应的DB端口。为了进一步限制访问，你可以创建DBAccess-Prod，-QA，-Dev等。通过云形成这样做可以简化这个过程。
顺便说一句，亚马逊发布了一个你可能想看的NIST 800-53参考架构。