amazon-web-services - 在 aws 中分离实时和测试环境的最佳方法

Question

我想在 AWS 中提供测试和实时环境。
我的环境包含 AWS 服务，如 Lambda、API-Gateway 等，用于测试目的和实时使用。

在 AWS 中分离测试环境和实时环境的最佳方法是什么？

创建一个拥有主账户的组织是个好主意吗？
将此主帐户用于实时环境，然后创建另一个帐户
哪个属于同一组织并将其用于测试环境？

Answer 1

有许多权衡范式 - 主要是处理您对管理开销和隔离的容忍度。

组织的两个帐户

正如您所提到的，有主组织帐户和测试帐户的模式。有一些想法表明，将面向客户的生产 Assets 放入主计费帐户是一种不必要的风险，因为该帐户中的妥协会危及整个组织。也就是说，这仍然是一个非常常见的模式。

三个以上的组织帐户

您可以使用您的主帐户来容纳您的联合并访问您的所有其他帐户，而不是其他任何帐户。这允许您在生产帐户上应用服务控制策略以更好地保护它并限制妥协的范围。如果您想深入研究，您可以将您的身份联合工作放在自己的帐户中，但在您接受这种(或更多)复杂性之前，请确保它满足业务需求或降低与业务相称的风险成本。

与 IAM 分离

您可以在一个帐户中操作测试和实时环境，但由于管理开销，这可能是不可取的。如果您创建一组 IAM 策略/角色并在其名称前加上 TEST，并将它们与仅允许对名称开头带有 TEST 的其他资源的权限的策略一起使用(即，它们只能创建以 TEST 开头的资源，并且可以仅修改以 TEST 开头的资源)。然后对 LIVE 重复该过程。要分离数据，您可以使用 LIVE 和 TEST KMS key 以及仅向同一环境中的角色授予权限的策略。如果您使用 IAM 用户，您可以给他们 sts:assumeRole他们需要的任何 TEST 或 LIVE 角色的权限，他们可以使用控制台中的切换角色功能或 sts assume-role cli 或 api 上的命令来操作任一环境。与 lambda 交互的示例策略可能如下所示:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "ListActions",
            "Effect": "Allow",
            "Action": [
                "lambda:ListFunctions",
                "lambda:ListEventSourceMappings",
                "lambda:ListLayerVersions",
                "lambda:ListLayers",
                "lambda:GetAccountSettings",
                "lambda:CreateEventSourceMapping"
            ],
            "Resource": "*"
        },
        {
            "Sid": "TestOnly",
            "Effect": "Allow",
            "Action": "lambda:*",
            "Resource": [
                "arn:aws:lambda:*:337676836613:layer:TEST*:*",
                "arn:aws:lambda:*:337676836613:event-source-mapping:TEST*",
                "arn:aws:lambda:*:337676836613:function:TEST*",
                "arn:aws:lambda:*:337676836613:layer:TEST*"
            ]
        }
    ]
}

这不会阻止任一环境运行 list* api 调用并查看来自其他环境的资源的存在和/或名称，但是来自一个环境的资源将无法执行 describe* api 调用以查看有关其他环境中资源的任何信息/元数据，并且无法在其他环境中实例化新资源，也无法修改其他环境中的资源。通过 KMS 彻底锁定数据，您甚至无法在不使用中介的情况下在环境之间复制数据。但是，如果您希望服务具有不同的帐户范围设置/默认值(例如 ECS 中的 VPC 中继)，这将不起作用，因为它们是帐户范围的并且会影响您的所有环境。

但是，这需要一些精心设计的策略，除非您非常熟悉 IAM，否则使用 AWS Organizations 是一种更简单的方法。这种方式的优点是环境之间的分离非常明确。由于 AWS API 调用可以遍历账户，因此一个账户中的资源可以开始使用其他账户中的资源(承担角色、共享 S3 存储桶、共享 KMS CMK 等)。多账户策略可能会忽略这一点，随着环境随着时间的推移变得更加紧密，账户之间可能会出现不必要的泄漏。