在AWS中分离环境

时间:2019-03-21 16:56:51

标签: amazon-web-services aws-lambda amazon-dynamodb amazon-sns

在AWS中分离环境是否有最佳实践?

我有一个采用以下服务的解决方案:

  • Lambda
  • SNS
  • SQS
  • DyanmoDB
  • API网关
  • S3
  • IAM

我们还没有生活,但是我们正在接近。等我们上线的时候,我想要一个适当的生产,测试和开发环境,并在它们之间“合理地”隔离。

  1. 每个环境单独的帐户
  2. 每个环境一个帐户和一个单独的VPC

我阅读了慈善少校的文章AWS NETWORKING, ENVIRONMENTS AND YOU。我无法通过VPC进行细分,但是我不知道我堆栈中的所有服务都受VPC限制吗?这是我的一些要求:

  • 限制服务名称冲突(用于非全局服务)
  • 在环境之间建立非常清晰的界限
  • 最终,在环境级别授予权限

我正在使用AWS组织。

P.S。抱歉,如果这不是该问题的合适论坛。如果有更好的方法,请告诉我,我将其解决。

2 个答案:

答案 0 :(得分:4)

我建议每个环境一个AWS账户。原因(不分先后):

  1. 安全性:管理复杂的IAM策略以在单个帐户内创建边界确实很困难;相反,默认情况下,每个环境一个帐户强制设置边界:您可以启用跨帐户访问,但必须非常谨慎
  2. 当所有活动都发生在同一帐户中时,
  3. 审核访问您的不同环境会更加困难
  4. 性能:在VPC和非VPC上运行时,某些服务的性能特征不同(例如,在VPC中运行时,Lambda冷启动增加了延迟)
  5. 命名:您不必使用AWS账户ID来标识您正在使用的环境,而必须在账户中的所有资源中添加前缀或后缀-这是优先考虑的问题但尽管如此。
  6. 合规性:如果您需要遵守诸如HIPAA之类的合规性标准,该标准对可以保留数据的时间以及谁可以访问数据施加了严格的限制,则很难证明哪些数据是生产数据,哪些数据是测试数据等等(可以追溯到上面的#1和#2)
  7. 成本控制:在开发,测试和登台环境中,您可能希望授予人们相当广泛的权限来使用新资源,但设置较低的支出上限以防止意外的使用高峰;相反,在生产帐户中,您将需要有限的能力来分配资源,但要提高支出上限;易于通过单独的帐户执行-在同一帐户中执行的操作不多

我错过了什么吗?可能!但这就是为什么我要使用单独的帐户的原因。

顺便说一句-我不是提倡使用VPC。它们的存在是有原因的,您绝对应该使用VPC进行网络隔离。我要争辩的是,也使用DynamoDb,Lambda,SQS,S3等其他服务的任何人-VPC并不是IMO隔离资源的方法。

如果您使用的工具不够灵活,无法部署到其他帐户,那么我认为每个阶段一个帐户的弊端主要是连续部署。

最后,有些人希望将计费作为一个可能的问题,但实际上,您是否不想知道您在生产,登台或开发上花费了多少钱?!

答案 1 :(得分:1)

对于每种环境,请避免使用单独的帐户,以免增加访问共享资源的复杂性和障碍。 尝试使用:

相关问题