简介这份资源面向云计算工程师、DevOps 实践者及准备 AWS 认证的中高级学习者围绕 AWS Landing Zone 的自动化部署与测试展开提供可落地的代码示例与配套文档帮助解决多账户组织架构搭建、安全基线配置与合规策略验证等实际问题。压缩包共 69 个文件约 1.85MB以 json 策略模板、md 说明文档、yml CloudFormation 配置为主辅以 rb 校验脚本、test 与 cleanup 测试用例及少量 pdf、docx 参考资料覆盖组织单元与 SCP 管理、VPC 多层级模板、CloudTrail 与 Config 启用、S3 桶策略、联邦访问与成员账户管理等模块。资源已有 310 人学习目录按 cloudformation-tools、test-environment-setup、organizations、security、accounts 等分层组织便于按主题检索。读者可据此搭建测试环境、复用策略模板并理解自动化测试流程适合作为 Landing Zone 落地的参考骨架。1. 从一份“能跑起来”的 Landing Zone 示例说起多账号环境最怕的不是建不起来而是建起来之后没人敢动。我见过一个团队账号结构靠手工点出来半年后想加一条组织级防护策略结果发现三个账号的 OU 归属对不上回滚方案也没有最后只能挑个周末停机重来。这份landing-zone资源就是冲着这个痛点来的它把 AWS Landing Zone 的自动化编排和测试代码打包成可复现的示例用 Python 驱动基础设施定义、策略校验和回归测试适合正在搭多账号底座、或者想把已有底座纳入自动化管线的从业者。它不承诺开箱即用但给了你一套能照着改的骨架以及一套能证明“改完没坏”的测试思路。2. 拆开代码包Python 在 Landing Zone 里到底管什么2.1 目录结构与职责边界拿到这类资源先别急着跑入口脚本先看目录怎么分层。常见的组织方式是三层infra/放账号、OU、策略这些基础设施定义tests/放校验和回归用例scripts/放入口和工具函数。Python 在这里不是替代 IaC 工具而是做“编排层”和“验证层”——调用底层 API、拼装参数、跑断言。目录/文件典型职责改动频率infra/账号工厂、OU 结构、SCP 策略定义低结构稳定后少动tests/策略合规校验、资源存在性断言高随策略演进持续补scripts/入口脚本、参数解析、结果汇总中按流程调整config/环境参数、账号清单、区域配置中按环境差异维护这个分层的价值在于基础设施定义和测试用例解耦改策略不用动测试框架补测试不用碰编排逻辑。我一般会先确认config/里的参数是不是外部注入的如果是硬编码在脚本里后面多环境复现会很难受。2.2 入口脚本的参数解析与执行链路入口脚本通常用argparse收参数再按阶段分发。下面是一个典型的骨架参数名按你实际资源里的命名替换import argparse import logging from pathlib import Path def build_parser(): parser argparse.ArgumentParser(descriptionLanding Zone 编排入口) parser.add_argument(--stage, choices[plan, apply, verify], requiredTrue, help执行阶段plan 只做差异预览apply 落地verify 跑校验) parser.add_argument(--config, typePath, defaultPath(config/base.yaml), help环境配置文件路径) parser.add_argument(--dry-run, actionstore_true, help只打印将要执行的动作不调用变更接口) parser.add_argument(--log-level, defaultINFO) return parser def main(): args build_parser().parse_args() logging.basicConfig(levelargs.log_level, format%(asctime)s %(levelname)s %(message)s) logging.info(stage%s config%s dry_run%s, args.stage, args.config, args.dry_run) # 按 stage 分发到对应模块plan 阶段只读apply 阶段才允许写 if args.stage plan: run_plan(args.config, dry_runTrue) elif args.stage apply: run_apply(args.config, dry_runargs.dry_run) else: run_verify(args.config) if __name__ __main__: main()这段代码的关键不在语法而在--stage的三段式设计plan强制只读apply才允许变更verify独立跑校验。参数说明里--dry-run和--stage plan有重叠实际使用时建议二选一避免“以为在预览其实在落地”的翻车。--config用Path类型而不是字符串是为了后面拼路径时少踩类型错误。日志格式里带上 stage 和 config排错时能直接看出是哪次执行、哪份配置出的问题。2.3 账号工厂与 OU 结构的参数化账号和 OU 的创建是 Landing Zone 里最容易写死的地方。合格的示例会把账号清单抽成配置脚本只负责遍历和幂等创建。常见做法是配置里每个账号带name、email、ou_path、tags四个字段脚本先查存在性再决定创建还是跳过def ensure_account(session, spec): 幂等创建账号已存在则跳过不存在才发起创建 existing find_account_by_email(session, spec[email]) if existing: logging.info(账号已存在跳过: %s, spec[name]) return existing[Id] if spec.get(dry_run): logging.info(dry-run 模式不创建: %s, spec[name]) return None resp session.client(organizations).create_account( Emailspec[email], AccountNamespec[name], ) return resp[CreateAccountStatus][Id]find_account_by_email需要你自己按资源里的实现补核心是先查后建。dry_run放在账号 spec 里而不是全局是为了支持“部分账号预览、部分账号落地”的灰度场景。这里有个参数边界Email在组织内必须唯一配置里重复的邮箱会在创建时直接报错建议在加载配置阶段就做一次去重校验别等到调用接口才发现。3. 测试层怎么搭把“改完没坏”变成可执行的断言3.1 策略校验用例的写法Landing Zone 的测试重点不是单元测试覆盖率而是策略合规。典型断言包括指定 OU 下必须挂某条 SCP、关键账号不能脱离组织、防护服务必须在目标区域开启。用pytest组织时建议按“资源类型 断言维度”拆文件一个用例只验证一件事import pytest pytest.mark.parametrize(ou_name,expected_policy, [ (core, deny-root-user), (workload, require-mfa), ]) def test_ou_has_required_policy(org_client, ou_name, expected_policy): policies list_policies_for_ou(org_client, ou_name) assert expected_policy in policies, ( fOU {ou_name} 缺少策略 {expected_policy}当前挂载: {policies} )parametrize把 OU 和期望策略做成表加一条策略只加一行数据不用复制用例。断言消息里带上当前实际挂载的策略列表失败时不用再去控制台翻。org_client建议做成 fixture统一处理凭证和区域避免每个用例各写一套初始化。3.2 回归测试与 CI 的衔接测试写完要能自动跑。常见做法是在 CI 里分两段PR 阶段只跑只读校验策略存在性、配置合法性合并后才跑需要变更权限的用例。这样既保证每次改动都有校验又不会让只读环境的人被权限卡住。衔接时注意两点一是测试用例要能区分“只读断言”和“需要变更的断言”用 marker 打标签二是失败输出要落到日志文件CI 页面只展示摘要细节靠日志回溯。我一般会在入口脚本里加一个--report参数把校验结果写成 JSON方便后续做趋势对比。4. 避坑与排查五条血泪经验4.1 现象plan 阶段显示无差异apply 后却报资源冲突原因通常是 plan 读的是缓存或旧状态而 apply 走了实时接口两者不一致。解决plan 和 apply 必须用同一份配置快照入口脚本里把配置路径和哈希打进日志apply 前比对哈希不一致直接中止。4.2 现象账号创建成功但 OU 归属不对原因是创建和移动是两步操作中间失败会留下“账号在根下”的中间态。解决把“创建 移动 打标签”做成一个带补偿的流程移动失败时记录待处理清单下次执行优先补移动而不是重新创建。4.3 现象策略校验在本地通过CI 里失败多半是区域或凭证上下文不同。解决fixture 里显式固定区域凭证来源统一走环境变量禁止用例内部各自初始化客户端。校验用例里把实际区域打进断言消息失败时一眼看出跑在哪个区域。4.4 现象dry-run 模式仍然产生了变更检查dry_run是不是只传到了部分模块。常见疏漏是账号创建读了 dry_run但策略挂载没读。解决把 dry_run 做成执行上下文的一部分所有写操作统一从上下文取而不是各函数各自传参。4.5 现象测试越写越慢最后没人跑原因是回归用例里混进了真实创建操作。解决只读断言和变更断言用 marker 分开PR 只跑只读变更用例按需触发。慢用例单独放一个目录CI 里设超时超时即失败逼着大家保持用例轻量。5. 进阶把校验结果做成可对比的趋势跑通之后真正有价值的是“每次改动前后合规状态有没有退化”。我一般会在verify阶段把结果落成结构化数据字段包括检查项、目标资源、通过与否、时间戳然后按天聚合。下面是一个最小的结果落盘示例import json from datetime import datetime, timezone def dump_report(results, pathreports/verify.json): payload { generated_at: datetime.now(timezone.utc).isoformat(), total: len(results), failed: [r for r in results if not r[passed]], items: results, } with open(path, w, encodingutf-8) as f: json.dump(payload, f, ensure_asciiFalse, indent2)failed单独抽出来是为了让下游一眼看到退化项items保留全量供趋势分析。参数上注意时间戳统一用 UTC避免跨时区对比时错位。落盘路径建议按日期分目录方便做“本周 vs 上周”的对比。验证方法上我习惯做一次“故意破坏”测试手动摘掉一条策略跑verify确认报告里failed非空且指向正确资源再恢复。这一步能证明校验不是摆设。另一个技巧是把报告和配置哈希绑定同一份配置重复跑结果应该完全一致不一致就说明有隐藏的状态依赖。从那以后我每次改 Landing Zone 相关脚本都强制先跑一遍 plan 加 verify确认差异和合规状态都在预期内才允许 apply。这套习惯救过我好几次尤其是多人同时改配置的时候。希望帮到你。本文还有配套的精品资源点击获取