57 lines
4.5 KiB
Markdown
57 lines
4.5 KiB
Markdown
---
|
||
title: "CTP Topic 1 Gruntwork Landing Zone Architecture"
|
||
type: source
|
||
tags: [AWS, Landing-Zone, Gruntwork, CTP, Terraform, CI/CD]
|
||
sources: []
|
||
last_updated: 2026-05-06
|
||
---
|
||
|
||
## Source File
|
||
- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-1-gruntwork-landing-zone-architecture.md]]
|
||
|
||
## Summary（用中文描述）
|
||
- 核心主题：基于 Gruntwork 的 AWS Landing Zone 架构设计，包括参考架构、多账户结构和 CI/CD 流水线。
|
||
- 问题域：如何在云转型项目中快速构建符合最佳实践的多账户 AWS 基础设施。
|
||
- 方法/机制：参考架构（Reference Architecture）提供起点 → Landing Zone 基于 Gruntwork 仓库由产品团队自定义 → Jenkins CI/CD 自动化部署 → Git 特性分支工作流。
|
||
- 结论/价值：Gruntwork 提供经过实战验证的 Terraform 模块，是 AWS 基础设施最佳实践的集合；Landing Zone 在此基础上由各产品团队填充具体业务服务。
|
||
|
||
## Key Claims（用中文描述）
|
||
- Gruntwork 是拥有大量 Terraform 代码的组织，其代码经过多次实践验证，被认为是最佳实践。
|
||
- 参考架构（Reference Architecture）是包含核心账户（Shared/Logs/Security）和工作负载账户（Prod/Stage/Dev）的最佳实践起点。
|
||
- Landing Zone 基于 Gruntwork 但由产品团队自行定义具体服务，不包含 ECS 集群或 RDS 数据库等具体实现。
|
||
- 安全账户使用联邦用户（Federated User），通过 AD 组映射到 IAM 角色，替代传统 IAM 用户。
|
||
- 每个 Landing Zone 配备独立的 Jenkins 服务器来部署基础设施变更，每个产品团队也有自己的 Jenkins 任务。
|
||
- Git 工作流采用特性分支开发，通过 Pull Request 合并到主分支。
|
||
- Gruntwork 的 Terraform AWS 服务目录强调服务应具有业务上下文，而非简单的资源堆砌。
|
||
|
||
## Key Quotes
|
||
> "Gruntwork is a company that has put together a lot of Terraform code, and it's a collection of best practices." — Gruntwork Landing Zone 核心价值定位
|
||
|
||
> "Landing Zone is based on Gruntwork, but it doesn't have ECS clusters or RDS databases — it's defined by the product team." — Landing Zone vs Reference Architecture 的关键区别
|
||
|
||
> "Security account uses federated users, mapping AD groups to IAM roles, instead of traditional IAM users." — 联邦用户替代 IAM 用户的身份管理策略
|
||
|
||
## Key Concepts
|
||
- [[Reference-Architecture]]：包含核心账户（Shared/Logs/Security）和工作负载账户（Prod/Stage/Dev）的最佳实践起点。
|
||
- [[Landing-Zone-Architecture]]：基于 Gruntwork 仓库的 AWS 多账户基础设施部署单元，每个 Zone 有独立 GitHub 仓库管理 IaC。
|
||
- [[Terraform-Modules]]：Gruntwork 提供的经过实战验证的 Terraform 模块，强调服务具有业务上下文。
|
||
- [[Federated-Access]]：通过 AD 组映射到 IAM 角色的联邦身份访问，简化安全账户管理。
|
||
- [[CI-CD-Pipeline]]：基于特性分支 + Pull Request + Jenkins 的 Terraform 基础设施变更自动化流程。
|
||
|
||
## Key Entities
|
||
- [[Gruntwork]]：AWS Landing Zones 基础设施框架提供方，提供经过实战验证的 Terraform 模块库。
|
||
|
||
## Connections
|
||
- [[ctp-topic-9-ci-cd-with-gruntwork]] ← extends ← [[ctp-topic-1-gruntwork-landing-zone-architecture]]（CI/CD 流水线是 Landing Zone 部署的核心机制）
|
||
- [[ctp-topic-2-git]] ← depends_on ← [[ctp-topic-1-gruntwork-landing-zone-architecture]]（Git 工作流是 CI/CD 的前提）
|
||
- [[ctp-topic-3-deploy-and-maintain-infrastructure]] ← extends ← [[ctp-topic-1-gruntwork-landing-zone-architecture]]（Terraform 部署是 Landing Zone 的 IaC 实践）
|
||
- [[ctp-topic-17-active-directory-services-in-gruntwork-aws-lzs]] ← extends ← [[ctp-topic-1-gruntwork-landing-zone-architecture]]（AD 集成是 Landing Zone 安全账户的核心）
|
||
- [[ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security]] ← extends ← [[ctp-topic-1-gruntwork-landing-zone-architecture]]（数据标签是 Landing Zone 安全配置的基础）
|
||
|
||
## Contradictions
|
||
- 与 [[ctp-topic-35-aws-landing-zone-design-refresher-saas-labs]] 冲突：
|
||
- 冲突点：Landing Zone 中产品的定义粒度
|
||
- 当前观点（CTP Topic 1）：Landing Zone 由产品团队自行定义具体服务（ECS/RDS 等），产品团队有较大自主权
|
||
- 对方观点（CTP Topic 35）：Landing Zone 产品定义应更严格，由架构团队统一规划
|
||
- 状态：视角互补而非直接矛盾——CTP Topic 1 强调灵活性，CTP Topic 35 强调标准化，可能反映不同组织规模和治理成熟度的差异
|