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