我是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派。你是做什么?在操作和可伸缩性方面有什么意义?
这不是一个编程问题,可能更适合ServerFault.com。 –