如何区分不同的AWS环境 - 开发,测试,阶段,生产?

时间:2014-09-18 09:38:53

标签: amazon-web-services amazon-iam

我希望在AWS中拥有不同的环境。起初,我想过通过AWS Resources上的Tags,tags来区分环境。但后来我无法限制用户更改机器的标签。这意味着,如果我允许它们ec2:CreateTags,它们不仅可以创建标记,还可以更改任何资源的标记,因为不能对其应用条件 - 例如,如果它属于特定的VPC或子网。如果我不允许它们创建标记的优先级,那么它们可以启动一个实例但是它们的标签不会被应用,因此不允许对该实例进行任何进一步的操作。

如果我想通过VPC-ID来区分环境,那么对于诸如ec2:StartInstance之类的操作,不能应用条件来仅允许在特定VPC-ID中进行操作,而是可以基于资源标记有条件地允许由于前一段中的原因并不令人信服。

在AWS documentation 上提及

  

Working with AWS Access Credentials中讨论了维持这种分离的一种方法,即在开发和生产资源中使用不同的帐户。

因此,可以为其他几个本身就是支付账户的账户设立一个支付账户?我仍然认为不同环境的多个帐户不是一个好主意。

您如何区分执行政策的环境?

感谢。

3 个答案:

答案 0 :(得分:3)

不同的帐户是要走的路。有很多地方你想要创建隔离,你会在一个帐户内尝试做到这一点。考虑一下 - 有网络控制,所有服务的所有IAM权限,访问控制列表,具有您描述的限制的标签,以及不断。真正的隔离来自于现在把东西放在不同的帐户中。

你想要的最后一件事是你的开发环境中的一些弱点,以转移到你的生产环境 - 故事的结尾。还要考虑分离产品和开发帐户的生产效率......你永远不会因为错误或开发实验而破坏产品系统。

合并结算是支付所有费用的答案。易于设置和跟踪。如果您需要更多报告,请查看CloudAbility。

这在真正有趣的地方是在多个生产和多个开发环境的空间。那里有很多关于隔离的意见。有些人把所有的prod和dev组合成两个帐户,有些人把每个prod和dev都放到他们自己的帐户中。这一切都取决于您的风险状况。只是不要像CloudSpaces那样结束。

答案 1 :(得分:1)

可以执行consolidated billing,其中一个帐户根据自己的使用情况计费+任何其他关联帐户的AWS使用情况。但是,您无法拆分该帐单(例如,让主帐户仅支付链接帐户上的EC2服务,同时让链接帐户支付其他用途,例如S3等。)

至于区分环境,我为每个环境使用了不同的security groups(开发,登台,生产)作为标签的替代方案,但在执行策略时存在限制。完全控制策略的最佳选择是使用不同的帐户。

答案 2 :(得分:0)

我建议使用一个VPC并使用安全组进行隔离。随着AWS基础设施的增长,您将需要目录服务(名称服务器,用户目录,VM目录,查找服务等)。如果您有两个VPC,则共享目录服务并不容易。此外,如果你需要Code Repository(例如GitHub)或Build工具(例如Jenkins),它们有三个独立的VPC用于DEV,那么Staging和Production会让事情变得非常复杂。