5

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

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

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

4

3 回答 3

6

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

与组织的两个帐户

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

三个以上的组织帐户

您可以使用您的主帐户来容纳您的联盟和访问您所有其他帐户的权限，仅此而已。这允许您在生产帐户上应用服务控制策略，以更好地保护它并限制妥协的范围。如果您想潜入兔子洞，您可以将您的身份联合工作放在自己的帐户中，但在您接受这种（或更高）级别的复杂性之前，请确保它满足业务需求或降低与业务相称的风险成本。

与 IAM 分离

您可以在单个帐户中操作测试和实时环境，但由于管理开销可能不建议这样做。如果您创建一组 IAM 策略/角色并在其名称前加上 TEST，并将它们与仅允许在名称开头带有 TEST 的其他资源的权限的策略一起使用（即，它们只能创建以 TEST 开头的资源并且可以只修改以 TEST 开头的资源）。然后对 LIVE 重复该过程。要分离数据，您可以使用 LIVE 和 TEST KMS 密钥以及仅向同一环境中的角色授予权限的策略。如果您使用 IAM 用户，您可以授予sts:assumeRole他们所需的任何 TEST 或 LIVE 角色的权限，并且他们可以使用控制台中的切换角色功能或sts assume-rolecli 或 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 等）。多账户策略可能会忽略这一点，并且随着环境随着时间的推移变得更加紧密，账户之间不必要的泄漏成为可能。

于 2020-01-05T06:25:45.580 回答
1

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

面向项目的帐户层次结构

如何实现账户分离

首先，您需要使用您的主账户创建一个 AWS 组织，该账户将作为您的项目账户运行。然后，您可以通过邀请现有 AWS 账户将它们添加到您的组织，或者在 AWS Organizations 的帮助下创建新账户（在这种情况下，请注意可能存在的陷阱）。完成创建和组织帐户后，您将自动为每个帐户获得一个干净的沙箱环境，不会发生资源冲突。

您的好处

  • 您无需关心资源的正确前缀或后缀
  • 通过合并计费，您将清楚地了解每个资源堆栈和每个帐户的成本
  • 如果您从 AWS Organizations 界面创建每个账户，则不需要信用卡
于 2020-01-20T18:29:11.723 回答
0

可以利用 AWS elasticbean 服务来实现此功能。

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

更多详情，请参考以下链接： https ://docs.aws.amazon.com/elasticbeanstalk

希望这有助于开始。

于 2020-01-04T18:43:25.030 回答