AWS授权代理 AWS 亚马逊云账号组织架构设置
你有没有试过在AWS控制台里点开账单页面，发现一堆陌生服务费用——EC2明明没开几台，RDS却每天烧掉三百块？或者半夜被告警短信叫醒，发现某个开发小哥用根账号把生产S3桶删了，还顺手关掉了CloudTrail？又或者，财务部门拿着Excel表格来问：‘上个月市场部的Lambda花了多少钱？运维组的EKS集群呢？’你翻遍Cost Explorer，只看到一串ID和模糊的‘Other’分类……
别让一个账号扛下所有罪
AWS授权代理 很多人起步就建个根账号，填张信用卡，开干。这就像租了整栋写字楼，却把财务章、公章、员工门禁卡全塞进前台抽屉里——人来了发一张，走了也不收。初期省事，后期爆炸。AWS官方早就不止一次画重点：‘Single Account is Not a Strategy’（单账号不是架构，是赌徒行为）。不是危言耸听，而是血泪教训。
先想清楚：你要管的是‘人’，还是‘资源’？
组织架构的本质，不是技术炫技，而是对齐业务现实。你得先画三张图：
① 业务图：市场部跑A/B测试要临时起量；研发有核心产品线+创新孵化项目；安全部要独立审计环境；合规要求金融模块必须物理隔离。
② 角色图：谁只能看不能改？谁可以部署但不能删？谁需要跨部门协同访问日志？
③ 生命周期图：测试环境三个月后自动销毁，预发环境保留半年，生产环境永续但锁死变更窗口……
这些，一个账号永远理不清。
推荐架构：三层洋葱模型
我们不讲教科书式‘最佳实践’，只说经过17个客户验证、熬过3次大促压测、扛住4次红队渗透的真实架构：根账号→管理OU→业务OU，像剥洋葱一样层层包裹。
第0层：根账号（Root Account）——锁进保险柜
它唯一使命：创建和管理组织（Organization），其他功能一律禁用。具体操作：
• 禁用所有IAM用户、关闭所有服务（除了Organizations和Billing）；
• 启用MFA强制策略（连根账号登录都需硬件密钥）；
• 创建一个专用IAM角色OrgAdmin，仅允许organizations:*和billing:* 权限，且信任策略限定为管理OU中的特定账号；
• 把根账号凭证封进防火保险箱，贴上‘地震级事件才启用’标签。
第1层：管理OU（Management OU）——运维中枢
这里放3类账号：
• SecOps账号：托管GuardDuty、Security Hub、Config规则、Macie扫描——所有安全信号统一入口，禁止任何业务部署；
• LogArchive账号：接收全组织CloudTrail、VPC Flow Logs、Config历史，启用S3 Object Lock防篡改，存储周期设为7年；
• SharedServices账号：运行Jenkins Server、Terraform Cloud Backend、集中DNS（Route53私有托管区）、证书管理器（ACM）——这里不跑业务代码，只提供‘水电煤’。
关键技巧：给管理OU绑定SCP（Service Control Policy），例如：{"Version":"2012-10-17","Statement":[{"Effect":"Deny","Action":"ec2:RunInstances","Resource":"*","Condition":{"StringNotEquals":{"aws:RequestedRegion":["us-east-1"]}}}]}
意思是：管理OU下的账号，只能在美国东部1区启动EC2——避免误开新加坡实例导致合规风险。
第2层：业务OU（Business OUs）——按线作战
按业务线切分，不是按部门！比如：
• ou-abc1-12345678 → CoreProduct（含prod/staging/dev子OU）
• ou-abc1-87654321 → GrowthTeam（含ab-test/preview子OU）
• ou-abc1-99999999 → FinanceCompliance（单独OU，启用HIPAA白名单SCP）
每个业务OU内，强制启用账号分隔原则：
• dev-001：开发者自助创建，CI/CD流水线可部署，但无法访问生产密钥；
• staging-001：QA团队独占，启用自动化渗透扫描，每周自动快照备份；
• prod-001：仅允许通过CodePipeline发布，所有API调用记录到LogArchive账号，删除操作需双人审批（使用Session Manager会话审批插件）。
让权限‘看得见、管得住、收得回’
别再写‘AdministratorAccess’了。真正的权限治理，藏在三个地方：
SCP不是万能胶，而是安全围栏
很多人以为SCP是权限叠加，错！它是最终否决权。举个真实案例：某客户给Dev账号赋予了iam:CreateUser，但SCP中写了：{"Effect":"Deny","Action":"iam:CreateUser","Resource":"*","Condition":{"StringNotLike":{"iam:UserName":["ci-*","tf-*"]}}}
结果：开发者依然能创建用户，但用户名必须以ci-或tf-开头——自动过滤掉admin、root等高危命名。这才是精准管控。
跨账号角色：信任链比密码更可靠
拒绝用AccessKey共享！正确姿势：
• 在SecOps账号创建角色AssumeAuditRole，信任策略只允许CoreProduct/prod-001账号的CloudTrailDelivery角色扮演；
• 在prod-001中，为CloudTrail服务关联角色时，指定sts:AssumeRole目标为SecOps账号的ARN；
• 这样，CloudTrail日志自动投递到LogArchive，无需任何密钥轮换，且审计路径清晰可溯。
成本分摊：用标签逼出责任心
在组织根节点启用Tag Policies，强制所有EC2、RDS、Lambda必须带3个标签：
• Project=core-payment（对应业务线）
• Environment=prod（环境标识）
• [email protected]（个人责任制）
然后在Cost Explorer里按Project+Environment下钻，每月邮件自动发送TOP10耗资资源列表——当开发者看到自己名下的测试集群本月花了2.3万，下次删资源的手速会快10倍。
最后送你三条保命口诀
① 新账号上线前，先跑脚本：用AWS CLI执行aws organizations list-accounts --query 'Accounts[?Status==`ACTIVE`].{Name:Name,Id:Id}'，输出结果丢进Excel，人工核对‘名字是否规范’、‘是否归属正确OU’、‘是否有未授权的SCP绕过’；
② 每季度做一次‘断网演练’：临时移除管理OU的SCP，观察各业务OU是否仍能访问生产数据库——如果能，说明IAM策略存在越权，立刻修复；
③ 根账号永远不碰业务：曾有个客户为赶工期，直接在根账号里开了RDS，结果两年后迁移失败，因为根账号无法加入组织，成了‘数字孤岛’。
架构不是图纸，是呼吸的有机体。今天你多花两小时搭好OU层级，明天就能少熬三次通宵救火。毕竟，云不是让你更忙，而是让事情更静默地运转——静默到，只有账单变少时，你才会突然意识到：啊，原来它一直在好好工作。
