AWS账号批发 AWS亚马逊云代理商主子帐号管理
一、别再用Root账号当‘万能钥匙’了
想象一下：你是一家AWS认证代理商，手里管着37家客户的云资源——奶茶连锁店要扩店上云，SaaS初创公司急着跑AI模型，还有家制造业老厂刚把ERP搬上AWS……结果你掏出自己的Root账号，登录、创建EC2、开RDS、配S3桶，顺手还改了密码策略——完事儿？恭喜，你已成功把自己变成全网最危险的单点故障。
Root账号不是瑞士军刀，是核按钮。AWS官方文档第7次加粗提醒：‘Root账号仅用于首次账户设置和极少数紧急恢复操作’。可现实是，太多代理商把Root当日常工号使，客户一提需求，噼里啪啦一顿操作，账号日志里全是‘[email protected]’的幽灵足迹。等某天客户问‘上个月那笔$28,000的EBS快照费用谁干的？’——你翻遍CloudTrail，发现记录里只有一串匿名哈希值，连是谁点的‘全部删除’都查不到。
二、主子账号不是父子关系，是‘物业+租户’关系
先破个迷信：AWS里压根没有‘子账号’这个官方术语。所谓子账号，其实是独立AWS账户（AWS Account），通过组织（AWS Organizations）纳入同一管理单元，由主账号（通常是你的代理商业务主控账户）统一治理。它不是你账号的‘孩子’，而是你托管的‘租户’——你收租金（服务费）、管门禁（权限）、修水电（运维），但房子产权（账户所有权）永远归客户。
我们给客户建的每个AWS账户，都像一栋独立公寓楼：客户是业主，你拿的是物业管理员门禁卡，卡上写着‘仅限公共区域通行，禁止进入业主卧室’。这张卡怎么配？靠的是AWS Organizations + IAM Identity Center（原SSO）+ 精细策略控制。不是给你开个‘AdministratorAccess’就完事——那等于把整栋楼的消防栓、配电箱、监控室钥匙全塞给你，客户半夜发现你正用他们的KMS密钥解密财务数据，怕不怕？
▶ 主账号：你的‘中央调度室’
主账号不存客户业务数据，只装四样东西：账单汇总视图（Consolidated Billing）、组织策略（Service Control Policies, SCPs）、跨账户角色信任关系（Cross-Account Roles）、审计中枢（CloudTrail Organization Trail + Config Aggregator）。它像机场塔台——看得到所有航班（账户）起降，能发指令（SCPs限流），但不能替飞行员（客户）操纵飞机。
▶ 客户账号：真正的‘主权国家’
每个客户账号必须满足三项铁律：
① 独立Root邮箱：客户自己掌控，你绝不可留存密码或开启MFA设备；
② 默认禁用Root密钥：创建后立即执行aws iam delete-access-key --user-name root --access-key-id xxx；
③ 本地管理员组隔离：客户自建Admin-Local组，绑定AdministratorAccess策略，但该策略被主账号SCPs全局限制——比如禁止iam:CreateUser，防止客户自己建高危账号。
三、权限管理：不是‘给不给’，而是‘怎么给’
代理商最常犯的错，是把‘最小权限原则’理解成‘最小麻烦原则’——干脆给个PowerUserAccess，客户爱咋折腾咋折腾。结果某天客户工程师误删了整个S3存储桶，恢复花了17小时，赔偿3.2万。真问题不在技术，在授权逻辑。
▶ 四层权限防火墙
- 组织层（SCPs）：在主账号组织单元（OU）上挂策略，例如禁止所有客户账号调用
ec2:RunInstances启动t1.micro实例（太老旧易被挖矿）； - AWS账号批发 账户层（IAM策略）：客户账号内，为代理运维角色绑定
Agent-Ops-Role，策略中显式允许s3:GetObject但拒绝s3:DeleteBucket； - 资源层（Resource Policies）：S3桶策略写死
Principal只能是arn:aws:iam::123456789012:role/Agent-Ops-Role，连客户自己账号的管理员都无法直接访问； - 会话层（Permissions Boundaries）：为客户开发人员角色附加边界策略，限定其创建的Lambda函数最大内存为1024MB，防止单函数吃光预算。
▶ 实战策略模板（可直接抄作业）
这是我们在某跨境电商客户账号部署的运维角色策略片段（已脱敏）：
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:Describe*",
"ec2:StartInstances",
"ec2:StopInstances"
],
"Resource": "*"
},
{
"Effect": "Deny",
"Action": [
"ec2:TerminateInstances",
"ec2:CreateImage",
"iam:CreateUser"
],
"Resource": "*"
}
]
}注意那个Deny块——不是没写就默认禁止，而是明确宣告‘此操作绝对不许’。AWS策略评估时，Deny永远优先于Allow，这才是防手滑的终极保险栓。
四、成本分摊：让每一分钱都有户籍
客户说‘我要看上月CDN费用明细’，你打开主账号账单，发现$12,458.33混在37个账号的总账里——这就像拿着小区总水费单，告诉每户‘你们家用了多少自己猜’。破解方案只有两个字：标签（Tags）。
我们强制所有客户账号执行‘三级标签制’：
• ClientID: SH-2023-007（客户唯一编码）
• Environment: production（环境标识）
• Project: checkout-v3（项目归属）
然后在主账号Cost Explorer中，按ClientID维度拆分报表，自动邮件推送PDF账单。更狠的是，用AWS Budgets配置阈值告警——当某客户账号月消费超$5000，立刻触发Lambda函数，自动暂停其非核心EC2实例，并微信通知客户CTO。
五、那些年我们踩过的坑
- 坑1：SCPs锁死了，客户连自己账号都登不上——因为忘了在SCP中放行
sts:AssumeRole，客户用自己账号的IAM用户无法切换到本地管理员角色； - 坑2：跨账户S3复制失败——主账号角色信任策略没声明客户账号ID，错误提示‘InvalidToken’而非清晰的权限拒绝；
- 坑3：CloudTrail日志丢了——只启用了主账号Trail，忘了在客户账号启用
Organization Trail，导致客户自主操作无痕可溯。
六、最后送你一句大实话
主子账号管理不是技术炫技，是代理商业务的生命线。当你能对客户说‘您上个月的API调用异常峰值，已定位到test-env的Lambda未设并发限制，这是修复建议和费用影响分析’，而不是‘我看看啊…好像…可能…是哪个服务贵了？’——那一刻，你卖的不再是云资源，而是确定性。而确定性，永远比折扣率更贵。
所以，今晚下班前，请做三件事：
① 登录你的主账号，删掉所有Root密钥；
② 检查客户账号是否启用MFA for Root；
③ 把这篇文里的SCP模板，粘贴进你下一个新客户账号的组织单元。
做完这些，你离‘靠谱代理商’，就差一个客户发来的五星好评了。
