在aws中分离和测试环境的最佳方法

Question

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

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

创建一个具有主帐户的组织并将该主帐户用于活动环境，然后创建属于同一组织的另一个帐户并用于测试环境，这是一个好主意吗？

Answer 1

有许多与权衡的范例--主要是处理你对管理开销和孤立的容忍。

两个在各组织的帐户

正如您提到的，有主组织帐户和测试帐户的模式。有一些思路表明，将面向客户的生产资产放入主记帐帐户是不必要的风险，因为该帐户内的妥协会损害整个组织。尽管如此，这仍然是一个非常普遍的模式。

Three+在组织中的账户

您可以使用您的主帐户来存放您的联合帐户，并访问您的所有其他帐户，而不是其他任何帐户。这允许您在生产帐户上应用服务控制策略，以更好地保护它并限制折衷的范围。如果您想跳进兔子洞，您可以将您的身份联盟工作放在它自己的帐户中，但是在您接受这一级别(或更多的)复杂性之前，请确保它满足了业务需求，或者降低了与业务成本相称的风险。

IAM分离

您可以在单个帐户中操作测试和活动环境，但由于管理开销，这可能是不可取的。如果您创建了一组IAM策略/角色，并在它们的名称前加上了测试的前缀，并且使用它们的策略只允许在其他资源的名称开头使用测试权限(也就是说，它们只能创建以测试开头的资源，并且只能修改以测试开头的资源)。然后在现场重复这个过程。若要分离数据，可以使用活动和测试KMS键，其策略仅授予相同环境中角色的权限。如果您使用IAM用户，您可以在他们需要的任何测试或活动角色上授予他们sts:assumeRole权限，并且他们可以使用控制台中的开关角色特性或cli或api上的sts assume-role命令来操作任何一个环境。与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组织是一种更容易的方法。这种方法的优点在于它非常明确地说明了环境之间的分离。由于API调用可以遍历帐户，因此一个帐户中的资源可以开始使用其他帐户中的资源(承担角色、共享S3存储桶、共享KMS CMK等)。多帐户策略可能忽略这一点，并且随着时间的推移，环境变得更加紧密，帐户之间不必要的泄漏就可能发生。

Answer 2

有AWS的不同项目和环境分离策略，你可以用它来实现你的目标。除了已经描述过的“IAM分离”方法之外，您还可以考虑尝试按帐户分离。这可能导致帐户层次结构类似于来自这个AWS回答的下图。

​

​

如何实现账户分离

首先，您需要使用您的主帐户创建一个AWS组织，该帐户将作为您的项目帐户运行。然后，通过邀请现有的AWS帐户或在AWS组织的帮助下创建新的帐户(在本例中需要注意可能的陷阱)，将它们添加到组织中。在您完成创建和组织帐户之后，您将自动为每个帐户获得一个干净的沙箱环境，在那里不会发生资源冲突。

你的利益

• 您不需要注意资源的正确前缀或后缀
• 通过统一计费，您将清楚地了解每个资源堆栈和每个帐户的成本。
• 如果您从AWS组织界面创建帐户，则不需要为每个帐户提供信用卡。

Answer 3

可以利用AWS弹性be服务来实现此功能。

下面是代码片段:如果应用程序使用蓝色/绿色部署，则需要您的环境独立于生产数据库运行。例如，如果您的环境中附加了Amazon实例，数据将不会传输到您的第二个环境，如果您终止原始环境，数据将丢失。

详细信息，请参阅以下链接：https://docs.aws.amazon.com/elasticbeanstalk

希望这能帮上忙。