0

我是AWS架构师。我最近走进了一个帐户,该帐户存在一些主要的设计缺陷,目前正在将这些应用程序集成到系统中。AWS VPC子网划分方法

在我看来,子网太大了,一个适合所有人的心态,最终导致懒惰的安全组打开整个子网(/ 24s和/ 25s)甚至整个VPC的端口。另外,由于操作系统内部存在硬件静态IP地址,因此有些应用程序需要很长的交付时间才能将其移动到错误的子网,从而再次移动这些应用程序。由于其他应用程序驻留在那里,因此我们无法将子网从公共更改为私有。 OY!

我的问题!

什么是为50-150服务器的SaaS(DEV,QA,分期,督促)/企业应用网络(内部应用)环境规划时,你对子网及其安全团体之间的关系?

如果您拥有用于所有应用程序的大型子网(例如:/ 24 public,/ 24 private),则需要使用附加到前端层实例的安全组作为进一步向下的安全组的源地址能够1)只允许来自特定服务端口的特定来源的流量2)成为自动调节的候选对象,对吗?否则,你将需要管理单个IP作为源地址来限制流量,这将是1)巨大的痛苦2)不能自动调整或通过打开来自整个不安全的子网/ vpc的流量来自动调整。

我的替代子网网络设计较小的子网是这样的 -

具有较小的子网(/ 27s和/ 28S,/ 26S),只允许从相应的子网流量:

Web层A(/ 27 )(AZ-A) Web层B(/ 27)(AZ-E)

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

应用层安全组只有服务p允许的流量从Web层A & B使用Web层A/B CIDR作为源网络。这将允许通过安全组进行自动调节和控制子网之间的流量。在这个模型中,我们不会使用其他被安全组在我们的SG人士透露,预计可能与负载均衡使用..

问题要问你的..选择哪一个?我觉得随着更小,他们可以用作积木,每个应用程序都有自己的子网层......慢慢地雕刻出VPC派。你是做什么?在操作和可伸缩性方面有什么意义?

+0

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

回答

3

我也是一个AWS建筑师,而在我看来,如果你正在做的通过IP地址访问你就错了。

有许多不同的方法来分离开发,测试,QA和PROD环境中,所有的都是有效的根据您的要求。您可以将不同的环境放在不同的AWS账户中完全隔离。您还可以考虑单独的VPC,或者简单地将VPC内的子网分开。通过单独的子网,您可以通过路由规则限制访问,并且为每个环境创建单独的安全组。

安全组应授权访问其他安全组,而不是IP地址。假设您有一个Web应用程序和一个数据库服务器。创建一个“DBAccess”组 - 它不必有任何规则 - 并将其分配给您的Web实例。然后创建一个“DBServer”组,它将打开适当的DB端口到任何在“DBAccess”组下运行的端口。为了进一步限制访问,您可以创建DBAccess-Prod,-QA,-Dev等。通过云形成来实现这一过程简单。

顺便说一句,亚马逊已经发布了NIST 800-53参考架构,您可能想看看。