Auto-sync: 2026-04-29 00:02

wiki/overview.md

@@ -288,6 +288,8 @@ Cloud Transformation Programme (CTP) materials cover AWS landing zones, EKS, Ter
 
 **[[ctp-topic-18-wide-area-networking-in-aws-cloud]]**（CTP Topic 18）：AWS 广域网架构设计——Micro Focus IT 网络架构师 Christian Deckelman 主讲。核心架构：全球划分为 APJ/EMEA/AMS 三个地理区域，每个区域设立 Hub（如 EMEA 伦敦、AMS 俄勒冈），所有 Landing Zones 通过 TGW Peering 以星型拓扑接入区域 Hub，区域 Hub 之间全网状互联。现阶段 TGW 间路由依赖静态前缀列表，缺乏 BGP 动态路由，DR 场景需人工干预。演进路线：引入 Silver Peak SD-WAN 作为叠加网络实现动态路径选择；Pulse VPN 迁移至 Palo Alto Prisma Access (SASE) 实现就近接入并打通 SD-WAN 骨干。属 [[AWS-Transit-Gateway]] 架构实践，与 [[ctp-topic-25-labs-landing-zone-overview-itom-teams]]（Labs LZ 网络）和 [[ctp-topic-31-network-segregation-and-secure-access-to-the-new-aws-landing-zones]]（网络分段）共同构成 Landing Zone 网络知识体系。
 
+**[[ctp-topic-19-configuring-dns-within-aws-lzs]]**（CTP Topic 19）：AWS Landing Zone 环境下的 DNS 配置架构——Sankar Gopov 主讲。核心方案：在 Landing Zone 中设立专门的 DNS 账号集中管理 Route 53 私有托管区（PHZ）和解析规则，而非在每个业务账号中分散创建。关键技术组件：Route 53 Resolver 的 Inbound Endpoint（接收来自本地数据中心的解析请求）和 Outbound Endpoint（将 AWS 内部请求转发至 On-prem DNS）；AWS RAM 跨账号共享 Resolver Rules 给业务账户；跨账号 PHZ 关联必须先授权（Authorization）再关联（Association）。三种典型场景：从 AWS 访问本地资源（如 GitHub Enterprise）、从本地 VPN 访问 AWS 内部服务、账号间相互解析。Terraform 模块自动化部署，新账号上线即具备完整解析能力。属 [[AWS-Landing-Zone]] 网络基础服务层的核心实践，与 [[ctp-topic-18-wide-area-networking-in-aws-cloud]]（广域网）和 [[ctp-topic-31-network-segregation-and-secure-access-to-the-new-aws-landing-zones]]（网络安全）共同构成完整的 Landing Zone 网络知识体系。
+
 **[[ctp-topic-25-labs-landing-zone-overview-itom-teams]]**（CTP Topic 25）：Labs Landing Zone 运维团队视角——Labs LZ 基于 Gruntwork 参考架构，采用多账户策略，全部资源通过 Terraform/Terragrunt 管理（Jenkins 流水线扫描 GitHub 仓库变更触发 plan/apply）；核心账户包括：Shared（托管 Jenkins 主节点和加固 AMI）、Logs（CloudTrail/Config 日志集中存储）、Security（联邦用户和跨账户访问）、Core（AD 管理 Windows 实例和 IDP、DNS 管理 Swimford.net）、Network（Transit Gateway + JetPult 防火墙管理所有互联网流量，Pulse VPN 提供 Micro Focus 网络访问）、Shared Services（45 Arc Site 监控、Qualys 漏洞扫描）。Product Account 通过 Terraform 模块部署 subnet，需与网络团队协调 IP 范围和标签策略，防火墙通过标签自动配置网络访问策略。属 [[AWS-Landing-Zone]] Labs 视角的运维实践，与 [[ctp-topic-1-gruntwork-landing-zone-architecture]]（架构基础）和 [[ctp-topic-35-aws-landing-zone-design-refresher-saas-labs]]（SaaS vs Labs 职责划分）共同构成完整的 AWS Landing Zone 知识体系。
 
 **[[ctp-topic-31-network-segregation-and-secure-access-to-the-new-aws-landing-zones]]**（CTP Topic 31）：AWS Landing Zone 网络隔离与安全远程访问方案——解决 On-prem 系统和 VPN 用户因共享网络配置而可直接访问生产工作负载的安全风险。核心方案：①网络隔离通过 Checkpoint 防火墙启用 SPI 特性（default-deny），阻断内部网络对 AWS 网段的直接连通；②安全访问通过 AWS Systems Manager (SSM) 替代 VPN，用户假设 IAM 角色访问目标 EC2 实例上的 SSM Agent，支持浏览器会话和 AWS CLI 两种模式，提供双因素认证和 AWS 网络内安全连接。定位为 SD-WAN 实施前的过渡方案；长期演进目标为 IaC 化以消除控制台访问，break-glass 访问仅保留用于紧急场景。与 [[ctp-topic-18-wide-area-networking-in-aws-cloud]]（广域网架构）互补——后者关注如何打通网络，Topic 31 关注如何限制网络访问；两者共同构成 Landing Zone 网络知识体系。属 [[AWS-Landing-Zone]] 网络安全层的核心实践。
@@ -318,7 +320,7 @@ Cloud Transformation Programme (CTP) materials cover AWS landing zones, EKS, Ter
 
 **CTP Topic 10**（[[ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security]]）：AWS Landing Zone 部署、数据收集策略与基于标签的云原生安全架构——Steve Jarman 和 Pradeep 主讲。核心内容：①Landing Zone 部署前必须深入了解 BU 资产清单、IP 地址空间及数据敏感性；②DNS、Transit Gateway 等基础服务已通过 SRE 团队实现高度自动化；③**基于标签的安全控制机制**——传统基于 IP 的防火墙规则无法适应云环境动态性，转向利用 AWS 标签作为安全凭证；④**SCP 强制执行标签规范**——通过「显式拒绝」逻辑防止用户通过篡改标签绕过审计，确保资源创建时即具备正确的 BU/产品/环境归属；⑤**Checkpoint 防火墙有序层逻辑**——按优先级执行地理屏蔽 → BU 隔离 → 产品隔离 → 环境隔离，实现跨 VPC/On-prem/互联网的精细化流量控制；⑥Inline 层基于账号号的父子规则架构，简化跨账户策略管理。与 [[ctp-topic-1-gruntwork-landing-zone-architecture]] 的安全层扩展，与 [[ctp-topic-28-aws-tag-validation-tool]]（标签审计）共同构成标签治理闭环。
 
-**[[ctp-topic-45-automatic-ip-address-allocation-with-ipam]]**（CTP Topic 45）：Infoblox NIOS IPAM 自动分配 AWS VPC IP 地址——通过 YAML 配置文件声明期望子网大小和区域父 CIDR，NIOS 自动分配下一个可用 IP 地址块（≤/24 自动，>/24 需审批）；销毁 VPC 时自动从 IPAM Grid 清除条目；建立单一可信数据源，消除手工电子表格记录。属 [[IPAM（IP Address Management）]] 的机制层详解。
+**[[ctp-topic-45-automatic-ip-address-allocation-with-ipam]]**（CTP Topic 45）：IPAM 自动化替代 Excel 手工分配——Infoblox NIOS 作为核心 IPAM 引擎，通过声明式 YAML 配置文件（替代手工 network.yml）驱动 VPC IP 地址自动供给。传统模式：业务单元提出需求 → SRE 向网络团队申请 → 网络团队计算最优 CIDR → 更新电子表格 → SRE 准备 YAML；**新模式：用户仅声明业务联系人、工程联系人和期望子网大小（如 /22），NIOS 自动分配下一可用 IP 地址块，无需再与网络团队交接**。新 YAML 包含 parent_cidr（区域常量）、subnet_size 和 VPC 名称，支持多 VPC 和 AZ ID 指定。销毁 VPC 时自动从 IPAM Grid 清除条目，防止 IP 泄漏；系统向后兼容旧 YAML 配置。核心理念：**"We are not asking for IP address from the network team."** 属 [[IPAM（IP Address Management）]] 的机制层详解，与 [[ctp-topic-61-workload-vpc-provision-with-ipam-automation]]（应用层扩展）共同构成 IPAM 的"机制 → 应用"完整链路。
 
 **[[ctp-topic-61-workload-vpc-provision-with-ipam-automation]]**（CTP Topic 61）：Workload VPC 完整自动化供给方案——Pushka（Principal SRE）主讲，在 Topic 45 的 IPAM 自动分配机制基础上，展示了端到端 VPC 供给流程。核心增强：多 VPC 批量供给支持、邮件通知机制、CIDR /22 阈值自动审批（更大 CIDR 自动，更小需理由审批）、非路由 IP 地址（如 10.2.0.0/16）支持、使用 AZ ID 避免跨账号不一致。Infoblox Grid 作为全局唯一 IP 地址数据源防止重叠，架构包含休斯顿数据中心主库及冗余 DNS/NTP/DHCP 服务。核心理念：**"只需把信息放到正确位置，一切自动完成。"** 属 [[IPAM（IP Address Management）]] 的应用层扩展，与 [[ctp-topic-45-automatic-ip-address-allocation-with-ipam]] 共同构成 IPAM 的"机制 → 应用"完整链路。