如何在多账号和单账号选择

提示：本文详细阅读需要20-30分钟时间

概述：本文以使用S3+Glue+Redshift+MWAA（Airflow）为例，介绍使用两种不同方式区分Prod环境和Test环境的权限。

目录如下：

• 一、如何定义多账号和单账号
• 二、多账号的隔离效果测试
• 三、单账号下多用户的隔离效果测试
• 四、二者对比
• 五、小结

一、如何定义多账号和单账号

（一）多个独立AWS账户方案

1、定义

多账户的定义是创建多个AWS根账户，每个账户的ID是12位数字，例如0123456789012。账户与账户之间完全独立，可视为两个独立的公司。每个公司有独立的登陆入口，有独立的多个用户名和密码。例如：

• 生产账号： 987654321012
• UAT测试账号： 555566663333
• 开发账号： 111122223333

2、使用效果

（1）生产账号

• 登陆入口：https://987654321012.signin.aws.amazon.com/console
• 用户名 admin1，策略 AdministratorAccess
• 用户名 prod1，策略ProdAccess（编写Policy）
• 用户名 user1，策略 Readonly

（2）UAT测试账号

• 登陆入口：https://555566663333.signin.aws.amazon.com/console
• 用户名 admin1，策略 AdministratorAccess
• 用户名 user1，策略 Readonly

（3）开发账号

• 登陆入口：https://111122223333.signin.aws.amazon.com/console
• 用户名 admin1，策略 AdministratorAccess
• 用户名 user1，策略 Readonly

注：以上策略AdministratorAccess、Readonly是默认的IAM Policy，不需要编辑，创建账号即可使用。如果需要在多个Admin之间互相限制资源，那么需要自定义IAM Policy。

（二）单账户多IAM用户方案

1、定义

在一个账号内，创建多个IAM User，每个User绑定不同的策略，在策略中分别写明不同的资源的权限。

2、使用效果

所有用户统一登陆入口：https://888899990000.signin.aws.amazon.com/console

用户名和策略：

• 用户名 admin1，策略 AdministratorAccess
• 用户名 prod1，策略 prodPowerUserAccess
• 用户名 test1，策略 testPowerUserAccess
• 用户名 dev1，策略 devPowerUserAccess
• 用户名 readonlyuser1，策略 Readonly

3、IAM Policy 策略编写示例

在以上的用户体系中，需要额外编写一系列针对性的规则，一个典型的规则构成如下：

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": [
                "glue:GetDatabase",
                "glue:GetRegistry",
                "glue:GetCrawler",
                "glue:GetTables",
                "glue:ListSchemas",
                "glue:GetJobRun",
                "glue:GetSchema",
                "glue:GetWorkflow"
            ],
            "Resource": "arn:aws:glue:ap-southeast-1:133129065110:job/ETLJob01"
        },
        {
            "Sid": "VisualEditor1",
            "Effect": "Allow",
            "Action": [
                "glue:GetCrawlers",
                "glue:GetJobs",
                "glue:ListCrawlers",
                "glue:ListJobs"
            ],
            "Resource": "*"
        }
    ]
}

通过以上规则，可以相似的给特定的Glue/Redshift Resource分别赋予列表、读取、修改的权限。

二、多账号的隔离效果测试

（一）生产环境准备

在生产环境内，创建如下资源：

• S3存储桶
• Redshift生产集群
  • Glue ETL Job
  • Glue 爬虫
  • Glue 数据库
  • Glue 表
  • MWAA

（二）以测试环境账号登陆确认能否查看或修改生产环境

现在以测试环境账号登陆，确认是否能查看生产环境资源

1、查看S3资源

登陆后可发现，两个AWS账号之间的资源完全不可见。如下截图。

2、查看Redshift资源

登陆后可发现，两个AWS账号之间的资源完全不可见。如下截图。

3、查看Glue资源

登陆后可发现，两个AWS账号之间的资源完全不可见。如下截图。

4、查看MWAA资源

登陆后可发现，两个AWS账号之间的资源完全不可见。如下截图。

（三）结论

多账号可以实现完全的资源隔离。

（四）注意事项

原已经部署的资源，包括S3、Redshift、Glue、MWAA都是不支持换账户的。新开账户重新部署。

三、单账号下多用户的隔离效果测试

（一）单账号下多用户的隔离的测试方法

1、新建两个IAM组，分别名为ProdUserGroup和TestUserGroup

登陆到AWS控制台，通过IAM服务完成组的创建，分别取名为ProdUserGroup和TestUserGroup。

2、创建Prod和Test的新版本Policy

针对Prod生产环境，编辑如下Policy：

• ProdS3Policy
• ProdRedshiftPolicy
• ProdGluePolicy
• ProdMWAAPolicy

针对Test生产环境，编辑如下Policy：

• TestS3Policy
• TestRedshiftPolicy
• TestGluePolicy
• TestMWAAPolicy

3、分别将新创建的IAM Policy添加到对应的IAM User Group

其中ProdGroup对应Prod的Policy，TestGroup对应Test的Policy。

4、新建用户测试权限是否正常

新创建一个IAM用户，用户名为ProdTemp01，加入IAM组ProdGroup。然后使用这个新创建的用户登陆AWS控制台，验证这个用户看到的资源是否和Policy定义的预期的一样。

新创建一个IAM用户，用户名为TestTemp01，加入IAM组TestGroup。然后使用这个新创建的用户登陆AWS控制台，验证这个用户看到的资源是否和Policy定义的预期的一样。

（二）单账号下多用户的隔离的测试过程

1、S3 Policy 编写和测试

（1）S3 Prod 策略编写

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": [
                "s3:ListStorageLensConfigurations",
                "s3:ListAccessPointsForObjectLambda",
                "s3:GetAccessPoint",
                "s3:PutAccountPublicAccessBlock",
                "s3:GetAccountPublicAccessBlock",
                "s3:ListAllMyBuckets",
                "s3:ListAccessPoints",
                "s3:PutAccessPointPublicAccessBlock",
                "s3:ListJobs",
                "s3:PutStorageLensConfiguration",
                "s3:ListMultiRegionAccessPoints",
                "s3:CreateJob"
            ],
            "Resource": "*"
        },
        {
            "Sid": "VisualEditor1",
            "Effect": "Allow",
            "Action": "s3:*",
            "Resource": [
                "arn:aws:s3:::prod-1-mydemo/*",
                "arn:aws:s3:::prod-1-mydemo"
            ]
        }
    ]
}

（2）使用Prod用户登陆，查看S3资源清单

测试结果：可列出所有存储桶清单，但是不属于自己的存储桶，Access一列将显示为Error状态。如下截图。

（3）查看属于Prod自己权限的资源并发起操作

如配置预期，可正常列出属于自己权限的存储桶。如下截图。

测试新上传数据，上传通过。如下截图。

（4）查看不属于Prod自己的资源

如策略配置预期，提示没有权限。界面上所有操作按钮为灰色。如下截图。

（5）结论

IAM Policy可以实现S3桶分Prod和Test的独立授权。

2、Redshift Policy 编写和测试

（1）Redshift Prod 策略编写

策略内容如下（注：本策略允许用户使用Query Editor V1，但是只限于自己的查询语句，不能查看别人的查询语句）。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "GeneralPolicyToListAll",
            "Action": [
                "redshift:*",
                "redshift-serverless:*",
                "redshift:GetCluster*",
                "redshift:Describe*",
                "redshift:DescribeClusterDbRevisions",
                "ec2:DescribeAccountAttributes",
                "ec2:DescribeAddresses",
                "ec2:DescribeAvailabilityZones",
                "ec2:DescribeSecurityGroups",
                "ec2:DescribeSubnets",
                "ec2:DescribeVpcs",
                "ec2:DescribeInternetGateways",
                "sns:CreateTopic",
                "sns:Get*",
                "sns:List*",
                "cloudwatch:Describe*",
                "cloudwatch:Get*",
                "cloudwatch:List*",
                "cloudwatch:PutMetricAlarm",
                "cloudwatch:EnableAlarmActions",
                "cloudwatch:DisableAlarmActions",
                "tag:GetResources",
                "tag:UntagResources",
                "tag:GetTagValues",
                "tag:GetTagKeys",
                "tag:TagResources",
                "events:ListRules",
                "kms:DescribeKey",
                "kms:ListAliases"
            ],
            "Effect": "Allow",
            "Resource": [
                "*"
            ]
        },
        {
            "Effect": "Allow",
            "Action": "iam:CreateServiceLinkedRole",
            "Resource": "arn:aws:iam::*:role/aws-service-role/redshift.amazonaws.com/AWSServiceRoleForRedshift",
            "Condition": {
                "StringLike": {
                    "iam:AWSServiceName": "redshift.amazonaws.com"
                }
            }
        },
        {
            "Sid": "DataAPIForQueryEditorV1",
            "Action": [
                "redshift-data:ExecuteStatement",
                "redshift-data:CancelStatement",
                "redshift-data:ListStatements",
                "redshift-data:GetStatementResult",
                "redshift-data:DescribeStatement",
                "redshift-data:ListDatabases",
                "redshift-data:ListSchemas",
                "redshift-data:ListTables",
                "redshift-data:DescribeTable"
            ],
            "Effect": "Allow",
            "Resource": "*"
        },
        {
            "Sid": "SecretsManagerListPermissions",
            "Action": [
                "secretsmanager:ListSecrets"
            ],
            "Effect": "Allow",
            "Resource": "*"
        },
        {
            "Sid": "SecretsManagerCreateGetPermissions",
            "Action": [
                "secretsmanager:CreateSecret",
                "secretsmanager:GetSecretValue",
                "secretsmanager:TagResource"
            ],
            "Effect": "Allow",
            "Resource": "*",
            "Condition": {
                "StringLike": {
                    "secretsmanager:ResourceTag/RedshiftDataFullAccess": "*"
                }
            }
        },
        {
            "Sid": "DenyAllForTest",
            "Effect": "Deny",
            "Action": [
                "*"
            ],
            "Resource": [
                "arn:aws:redshift:*:*:cluster:test*"
            ]
        },
        {
            "Sid": "SecretsManagerPermissions",
            "Effect": "Allow",
            "Action": [
                "secretsmanager:CreateSecret",
                "secretsmanager:GetSecretValue",
                "secretsmanager:DeleteSecret",
                "secretsmanager:TagResource"
            ],
            "Resource": "arn:aws:secretsmanager:*:*:sqlworkbench!*"
        },
        {
            "Sid": "ResourceGroupsTaggingPermissions",
            "Effect": "Allow",
            "Action": [
                "tag:GetResources"
            ],
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "aws:CalledViaLast": "sqlworkbench.amazonaws.com"
                }
            }
        },
        {
            "Sid": "AmazonRedshiftQueryEditorV2Permissions",
            "Effect": "Allow",
            "Action": "sqlworkbench:*",
            "Resource": "*"
        }
    ]
}

以上策略以Prod为例。编写Test策略只需要响应替换即可。

（2）Prod生产用户查看Redshift集群清单

进入集群界面，可看到加载正常。加载首页两个集群的列表都可见。如下截图。

（3）通过QueryEditorV1在属于自己权限的集群运行查询语句

测试结果如下，可对自己所属的集群正常查询。如下截图。

（4）重启属于自己权限的Redshift集群

测试结果如下，可对属于自己权限的集群做重启操作。如下截图。

（5）Prod用户通过QueryEditorV1连接不属于自己权限范围的Test集群的测试

测试结果如下，可看到因为没有权限被拒绝。如下截图。

（6）重启不属于自己权限的Redshift集群

测试结果如下，提示没有权限。如下截图。

（7）Redshift 权限测试小结

IAM可对Redshift集群实现分Prod和Test环境做权限控制。在当个Redshift库内，如果还需要对库级别做权限控制，还需使用Redshift用户级别的授权实现。

3、Glue Policy 编写和测试

（1）Glue 策略编写

策略编写如下：

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": [
                "s3:*",
                "glue:GetJobs",
                "glue:ListJobs",
                "glue:GetCrawlers",
                "glue:ListCrawlers"
            ],
            "Resource": [
                "*"
            ]
        },
        {
            "Sid": "VisualEditor1",
            "Effect": "Allow",
            "Action": "glue:*",
            "Resource": [
                "*"
            ],
            "Condition": {
                "StringLike": {
                    "aws:ResourceTag/name": [
                        "prod*"
                    ]
                }
            }
        },
        {
            "Sid": "PermissionprodDatabase",
            "Effect": "Allow",
            "Action": [
                "glue:GetDatabases",
                "glue:GetDatabase"
            ],
            "Resource": [
                "arn:aws:glue:ap-southeast-1:166447082862:database/prod*",
                "arn:aws:glue:ap-southeast-1:166447082862:catalog"
            ]
        },
        {
            "Sid": "Permissionprodtable",
            "Effect": "Allow",
            "Action": [
                "glue:SearchTables",
                "glue:GetTable",
                "glue:GetTables",
                "glue:CreateTable"
            ],
            "Resource": [
                "arn:aws:glue:ap-southeast-1:166447082862:table/prod*/prod*",
                "arn:aws:glue:ap-southeast-1:166447082862:catalog"
            ]
        }
    ]
}

（2）Glue ELT Job 权限测试

以Prod用户身份进入Glue服务，在Glue ETL界面下，可看到所有用户的Glue ETL Job。如下截图。

点击自己有权限的Glue ETL Job，显式详情正常。如下截图。

查看自己没有权限的，可看到访问报错，提示没有权限。如下截图。

由此Glue ETL Job权限测试达到预期。

（3）Glue Clawlers 爬虫权限测试

以Prod用户身份进入Glue服务，在Glue Clawlers界面下，只能看到属于自己的Glue Clawlers。如下截图。

由此Glue Clawlers 爬虫权限测试达到预期。

（4）Glue Database 权限测试

以Prod用户身份进入Glue服务，在Glue Database界面下，只能看到属于自己的Glue Database。如下截图。

由此Glue Database 权限测试达到预期。

（5）Glue Table 权限测试

由于Glue Table是隶属于Glue Database的，因此在配置好IAM Policy后，Glue Database也可以实现完全的隔离。

以Prod用户身份进入Glue服务，从Table入口查看表是空白的。

以Prod用户身份进入Glue Database服务，然后点击自己有权限的Database，可看到所属的Table。如下截图。

由此Glue Table 权限测试达到预期。

4、MWAA Policy 编写和测试

（1）MWAA IAM Policy 编写范例

参考AWS官方给出的默认策略：

https://docs.aws.amazon.com/mwaa/latest/userguide/access-policies.html#access-policy-use-case

在这篇文档中，分别包含了：

• https://docs.aws.amazon.com/mwaa/latest/userguide/samples/AmazonMWAAFullConsoleAccess.zip
• https://docs.aws.amazon.com/mwaa/latest/userguide/samples/AmazonMWAAWebServerAccess.zip
• https://docs.aws.amazon.com/mwaa/latest/userguide/samples/AmazonMWAAAirflowCliAccess.zip

这个几个策略都是默认允许任意访问的最大权限策略。接下来需要给特定的分割Prod和Test的权限。

（2）查看现有MWAA的ARN和IAM Role

在如下截图中，可看到左侧的ARN部分，完整复制下来。例如arn:aws:airflow:ap-southeast-1:133129065110:environment/MyAirflowEnvironment就表示生产环境的ARN。如下截图。

以管理员身份进入MWAA控制台，向下滑动到页面最下方的Permissions部分，将Exceution role复制下来，本例中就是AmazonMWAA-MyAirflowEnvironment-vpCHGP，下一步配置策略要使用。如下截图。

（3）编写三个针对Prod用户的MWAA IAM Policy组合生效

编辑如下三个Policy：

• MWAAProdConsoleFullAccess
• MWAAProdDenyTestAccess
• MWAAProdWebUI

在这三个策略中，分别代入上一步查询获得的Prod生产环境的MWAA的ARN和IAM Role。

策略MWAAProdConsoleFullAccess内容如下：

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "airflow:*",
            "Resource": "arn:aws:airflow:ap-southeast-1:133129065110:environment/MyAirflowEnvironment"
        },
        {
            "Effect": "Allow",
            "Action": [
                "iam:ListRoles"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "iam:CreateServiceLinkedRole"
            ],
            "Resource": "arn:aws:iam::*:role/aws-service-role/airflow.amazonaws.com/AWSServiceRoleForAmazonMWAA"
        },
        {
            "Effect": "Allow",
            "Action": [
                "s3:GetBucketLocation",
                "s3:ListAllMyBuckets",
                "s3:ListBucket",
                "s3:ListBucketVersions"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "s3:CreateBucket",
                "s3:PutObject",
                "s3:GetEncryptionConfiguration"
            ],
            "Resource": "arn:aws:s3:::*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "ec2:DescribeSecurityGroups",
                "ec2:DescribeSubnets",
                "ec2:DescribeVpcs",
                "ec2:DescribeRouteTables"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "ec2:AuthorizeSecurityGroupIngress",
                "ec2:CreateSecurityGroup"
            ],
            "Resource": "arn:aws:ec2:*:*:security-group/airflow-security-group-*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "kms:ListAliases"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "kms:DescribeKey",
                "kms:ListGrants",
                "kms:CreateGrant",
                "kms:RevokeGrant",
                "kms:Decrypt",
                "kms:Encrypt",
                "kms:GenerateDataKey*",
                "kms:ReEncrypt*"
            ],
            "Resource": "arn:aws:kms:ap-southeast-1:133129065110:key/dff5e9ae-b074-47ea-b8ae-6d1e7e8e2714"
        },
        {
            "Effect": "Allow",
            "Action": [
                "iam:PassRole"
            ],
            "Resource": "*",
            "Condition": {
                "StringLike": {
                    "iam:PassedToService": "airflow.amazonaws.com"
                }
            }
        },
        {
            "Effect": "Allow",
            "Action": [
                "iam:AttachRolePolicy",
                "iam:CreateRole"
            ],
            "Resource": "arn:aws:iam::133129065110:policy/service-role/MWAA-Execution-Policy-*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "s3:GetEncryptionConfiguration"
            ],
            "Resource": "arn:aws:s3:::*"
        },
        {
            "Effect": "Allow",
            "Action": "ec2:CreateVpcEndpoint",
            "Resource": [
                "arn:aws:ec2:*:*:vpc-endpoint/*",
                "arn:aws:ec2:*:*:vpc/*",
                "arn:aws:ec2:*:*:subnet/*",
                "arn:aws:ec2:*:*:security-group/*"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "ec2:CreateNetworkInterface"
            ],
            "Resource": [
                "arn:aws:ec2:*:*:subnet/*",
                "arn:aws:ec2:*:*:network-interface/*"
            ]
        }
    ]
}

策略MWAAProdDenyTestAccess内容如下：

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": [
                "airflow:ListEnvironments",
                "airflow:GetEnvironment"
            ],
            "Resource": "*"
        },
        {
            "Sid": "Statement1",
            "Effect": "Deny",
            "Action": [
                "airflow:CreateEnvironment",
                "airflow:UpdateEnvironment",
                "airflow:DeleteEnvironment",
                "airflow:ListTagsForResource",
                "airflow:CreateWebLoginToken",
                "airflow:CreateCliToken",
                "airflow:UntagResource",
                "airflow:PublishMetrics",
                "airflow:TagResource"
            ],
            "Resource": "arn:aws:airflow:ap-southeast-1:133129065110:environment/test"
        }
    ]
}

策略MWAAProdWebUI内容如下：

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "airflow:CreateWebLoginToken",
            "Resource": [
                "arn:aws:iam::133129065110:role/service-role/AmazonMWAA-MyAirflowEnvironment-vpCHGP"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "airflow:CreateCliToken"
            ],
            "Resource": "arn:aws:airflow:ap-southeast-1:133129065110:environment/MyAirflowEnvironment"
        }
    ]
}

将以上三个策略都附加到Prod用户所属的ProdGroup组上，然后测试权限。

（4）以Prod用户测试MWAA权限

以Prod用户访问MWAA控制台列表页面，显示正常。如下截图。

以Prod用户身份，修改Prod资源的配置，修改参数正常。如下截图。

由此确认Prod用户可正常访问自己的资源，与预期一致。

（5）以Prod用户查看Test用户MWAA资源

以Prod查看Test用户的资源，可看到资源的配置信息可以被显示。如下截图。

当Prod用户试图修改Test用户的资源配置时候，提示权限被拒绝。如下截图。

此外，Prod用户点击Test环境的Open Airflow UI按钮时候，打开的新标签页也会拒绝访问，提示没有权限。

由此确认Prod用户可看到Test用户资源，但是不能查看任务也不能修改，与预期一致。

（三）单账号下多用户的隔离的测试结果

按照上述步骤进行测试，测试结果如下：

名称	功能	两个环境之间互相可列出资源清单	两个环境之间互相可查看配置详情	两个环境之间互相可操作修改资源
S3		是	否	否
Redshift	Cluster	是	否	否
Glue	Job	是	否	否
Glue	Crawlers	否	否	否
Glue	Database	否	否	否
Glue	Tables	否	否	否
MWAA		是*	否	否

注：MWAA可点击查看MWAA的Enironment配置详情界面，但是不能查看其他用户的MWAA任务。

四、多账户和单账户的对比

1、一些问题澄清

Q1：关于从现有架构如何去改动，如何评估改动成本

首先，AWS不支持本账号内的资源更换账户。因此如果生产账号为111122223333，已经部署了生产用S3、Glue、Redshift、MWAA。此时新创建了测试账号444455556666，那么所有S3、Glue、Redshift、MWAA是不能修改更换到新的账户中的。

如果要想在新的账号中使用S3、Glue、Redshift、MWAA服务，需要重新部署配置一次。由此，使用多账号存在改动成本的工作量。

使用单账号，划分IAM User仅仅是IAM Policy修改，已经部署到位的S3、Glue、Redshift、MWAA不需要重新部署。单账号的改动成本更小。

Q2：单账户内多个User使用IAM Policy权限来控制策略，是否可做到完全多个IAM User用户之间完全不可见？

并不完全不可见。单账户内的多个IAM User之间可列出其他人的资源清单，因此在List操作上时候是可以看见多人的资源。但是，点击不属于自己的资源，则立刻提示无权限。因此这里说的多个IAM User之间资源不可见，是指各资源服务名称和列表可见的情况下，服务详情、配置参数、以及各自数据之间不可见。

此部分的详细测试和验证流程，参考本文第三章节单账号的隔离效果测试。此环节可看出多账号隔离更彻底。

Q3：多AWS账户场景是否完全就不用学习编写IAM Policy策略编写方法了？

并不是。在多账户场景下，依然存在多人多IAM User管理的场景。虽然测试环境被切分到一个独立的AWS账户出去，但是以生产环境为例，其中部署了Glue、Redshift。但是，多个团队包括Admin、BI等都需要操作Redshift，或者分别操作多台Redshift。此时，场景还是回到了要通过IAM Policy限制多个IAM User之间的访问。

因此，使用多账户风格生产、测试环境后，在生产环境内还是需要编写IAM Policy。当然，由于测试环境独立在另一各AWS账户内，因此编写Policy的工作量显著下降。

2、两个模式对比

请参考如下对比表格：

对比	多账号分割生产和测试环境	单账号内多个IAM User区分生产和测试权限
登陆入口	多个网址，分别登陆。因为账号不同，因此不关心用户名是否相同	同一个登陆入口，用户名必须是唯一的才能区分
资源隔离	账号之间完全不可；生产和测试之间完全不可见	S3、Redshift、Glue Job服务，用户可以看到所有服务清单，但是只能操作自己的资源；Glue 爬虫、Glue Database、Glue Table服务，用户只能看到自己的资源
安全性	账户间默认完全隔离；单个账户内靠IAM Policy隔离多用户	单个账户内靠IAM Policy隔离多用户
现有架构改进带来的工作量	工作量大；新建测试账号后，需要重新部署测试资源；现有生产账号内，如果有多个用户，也需要配置IAM Policy	工作量小；不需要新建账号，只需要修改现有资源的IAM Policy
主要风险	如果只拆分测试环境，不影响业务运行，无业务运行风险；现有架构改进时候要新增测试账号，现有生产账号也要做多账号、或多用户的话，工作量大，时间成本为主，没有技术风险	不影响业务运行，无业务运行风险；现有账号配置大量IAM Policy，团队见沟通成本高，时间成本为主，没有技术风险
未来管理难点	账户间共享数据麻烦，需要配置IAM 跨账户	Policy 增加新的生产系统并且新增一组生产权限时候配置IAM Policy工作量大

五、小结

总结以上，考虑到实施改动工作量，可考虑如下两个方案：

方案（一）多账户：新账号内重新部署环境工作量大，但IAM Policy编写工作量小，另外隔离效果更好

方案内容：

• 生产环境1个账号，测试环境1个账号
• 生产环境内分别设置Admin、BI、Dev三个用户，用户之前通过IAM Policy隔离

主要工作内容和工作量：

• 新建第二个AWS账户作为测试账户
• 在测试账户内重新部署测试环境，在现有生产账户内停止原有测试环境
• 在现有AWS生产账户内配置IAM Policy区分多个管理员和部门

方案（二）单账户：现有环境不需要重新部署，总体工作量小，但IAM策略配置更复杂

方案内容：

• 当前AWS账号不变，同时运行生产和测试任务
• 分别设置Admin、BI、Dev、Test等多个用户，用户之前通过IAM Policy隔离
• 相对于方案一，不需要重新部署测试环境，只需要调整权限

全文完。