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

wiki/sources/ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security.md

@@ -1,55 +1,52 @@
 ---
 title: "CTP Topic 10 AWS Landing Zone (LZ) Data Collection, Tagging Related Security"
 type: source
-tags:
-  - AWS
-  - Landing-Zone
-  - Tagging
-  - Security
-  - CTP
-last_updated: 2026-04-14
+tags: []
+date: 2026-04-14
 ---
 
 ## Source File
-- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security.md]]
+- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security.md]]
 
 ## Summary（用中文描述）
-- 核心主题：AWS Landing Zone 的数据收集策略与基于标签的安全控制机制
-- 问题域：企业云迁移过程中的网络安全与访问控制
-- 方法/机制：
-  - 部署前通过业务部门（BU）资产清单、IP 地址空间及数据敏感性调研，制定 Landing Zone 安全姿态
-  - 利用 AWS 标签（Tagging）替代传统基于 IP 的防火墙规则，作为安全凭证
-  - 引入 OU（组织单元）和 SCP（服务控制策略）防止用户篡改标签绕过安全审计
-  - Checkpoint 防火墙通过"有序层（Ordered Layer）"逻辑实现流量分层过滤
-- 结论/价值：实现从传统网络安全向基于身份和元数据的云原生安全转型
+- 核心主题：AWS Landing Zone 环境下的资源数据收集、标签体系及基于标签的安全控制策略
+- 问题域：如何在大规模多账号云环境中实现标准化资源管理、标签规范落地、以及动态化的安全策略执行
+- 方法/机制：采用 OU（组织单元）分层 + SCP（安全控制策略） + 标签匹配的三层防护架构；通过 Checkpoint Firewall 基于标签的策略集实现动态流量控制，替代传统的 IP 地址规则；标签体系涵盖机器名、所有者（PDL）、类型、业务单元、产品、环境、服务器角色等维度；防火墙策略层按地理封锁 → 类型 → BU → 产品 → 环境 → 角色顺序逐层检查
+- 结论/价值：基于标签的策略使云环境具备动态伸缩能力，无需频繁调整防火墙规则；标签驱动的 SCP 可确保资源标记合规性和安全 posture 正确性
 
 ## Key Claims（用中文描述）
-- Steve Jarman + Pradeep 通过 SCP 的"显式拒绝"逻辑，强制执行标签规范，确保资源在创建时即具备正确的归属标签（BU、产品、环境）
-- Checkpoint 防火墙根据标签对流量进行分层过滤（地理屏蔽、BU 隔离、产品隔离、环境隔离），实现跨 VPC、On-prem 及互联网流量的精细化策略约束
-- DNS、Transit Gateway 等基础服务的创建已通过 SRE 团队实现高度自动化
+- 组织通过 OU 分层架构和标签校验机制，确保迁移至云端的资源正确标记并应用必要的安全控制（如：普通 ADM 用户无法擅自将标签改为 ITOM）
+- SCP（Security Control Policy）是基于标签匹配的拒绝策略，控制特定账号可使用的标签值，防止不合规资源进入云环境
+- 基于标签的防火墙策略集实现了动态云环境，策略以标签为依据而非 IP 地址，大幅减少防火墙规则维护工作量
+- 标签体系是云迁移规划的前提：收集机器信息 → 理解迁移范围 → 应用正确标签 → 触发安全策略
+- 防火墙策略的分层设计（Ordered Layers + Inline Layers）提供细粒度的流量管控：Ordered Layers 要求流量逐层通过，Inline Layers 采用基于账号编号的父子规则结构
 
 ## Key Quotes
-> "在部署前，必须深入了解业务部门（BU）的资产清单、IP 地址空间及数据敏感性，以便制定合适的安全姿态" — Steve Jarman，部署前规划原则
-> "通过 SCP 的'显式拒绝'逻辑，系统能够强制执行标签规范，确保资源在创建时即具备正确的归属" — Pradeep，标签安全控制机制
+> "We ask a lot of questions so that we can then turn around and make sure we're putting the appropriate posture in the cloud and that we're protecting the resources appropriately." — 关于云迁移前的标签规划重要性
+> "Inter product is not allowed. Inter product is communications allowed." — 关于跨产品线通信的防火墙默认策略
 
 ## Key Concepts
-- [[AWS Landing Zones]]：按照最佳实践快速设置安全且多账号 AWS 环境的基础架构框架
-- [[Tagging Methodology]]：通过为资源定义标准化元数据（如 Owner, BU, Product, Environment），作为自动化管理和安全策略执行的基础
-- [[SCP Service Control Policies]]：AWS Organizations 中的服务控制策略，用于管理组织中的权限，本视频中用于强制执行标签合规性
-- [[OU Organizational Unit]]：AWS Organizations 中账号的分组容器，用于分层应用安全策略（SCP）
-- [[Checkpoint Firewall Ordered Layer]]：防火墙策略的组织方式，按顺序执行地理屏蔽、BU 隔离、环境隔离等逻辑
-- [[Transit Gateway]]：传输网关，作为网络中心枢纽连接 VPC 与本地网络，是跨环境流量经过防火墙检查的关键节点
-- [[SRE Automation]]：站点可靠性工程，负责 Landing Zone 部署中的自动化脚本编写与基础架构维护
+- [[AWS-Landing-Zone]]：AWS 多账号环境的基础架构框架，包含 OU、SCP、账号结构等核心组件
+- [[SCP（Security-Control-Policy）]]：基于标签匹配的拒绝策略，控制特定 OU 中可使用的标签值
+- [[Resource-Tagging]]：云资源的关键元数据体系，涵盖机器名、所有者、类型、业务单元、产品、环境、服务器角色等维度
+- [[Ordered-Layer]]：防火墙策略层，要求流量依次通过各层检查，全部通过方可放行
+- [[Inline-Layer]]：基于账号编号的父子规则结构，简化跨账号策略管理
+- [[Checkpoint-Firewall]]：在 Landing Zone 中部署的下一代防火墙，支持基于标签的动态策略
 
 ## Key Entities
-- [[Steve Jarman]]：Cloud Transformation Programme 技术分享主持人，Landing Zone 规划与自动化专家
-- [[Pradeep]]：Checkpoint 防火墙与网络隔离技术演示主讲人
+- [[Pradeep]]：本主题演示者（Demonstrator），负责 Checkpoint Firewall 和 EC2 部署演示
+- [[AWS]]：云服务提供商，Landing Zone 架构的承载平台
+- [[Checkpoint]]：防火墙供应商，在 Frankfurt Landing Zone 部署防火墙策略集
 
 ## Connections
-- [[CTP Topic 1 Gruntwork Landing Zone Architecture]] ← builds_upon ← [[CTP Topic 10]]
-- [[CTP Topic 31 Network Segregation and Secure Access to the New AWS Landing Zones]] ← extends ← [[CTP Topic 10]]
-- [[CTP Topic 17 Active Directory Services in Gruntwork AWS LZs]] ← related_to ← [[CTP Topic 10]]
-- [[AWS_Organizations_and_SCP_Deep_Dive]] ← deep_dive ← [[CTP Topic 10]]（SCP 强制执行标签合规性）
+- [[CTP-Topic-7-SaaS-Landing-Zone-Design]] ← foundational ← [[CTP-Topic-10-AWS-Landing-Zone-LZ-Data-Collection-Tagging-Security]]（Topic 7 定义 LZ 设计原则，Topic 10 补充标签驱动的安全实现）
+- [[CTP-Topic-31-Network-Segregation-AWS-Landing-Zones]] ← extends ← [[CTP-Topic-10-AWS-Landing-Zone-LZ-Data-Collection-Tagging-Security]]（Topic 31 聚焦网络隔离，本主题提供标签驱动的安全策略执行层）
+- [[CTP-Topic-25-Labs-Landing-Zone-Overview-ITOM]] ← related ← [[CTP-Topic-10-AWS-Landing-Zone-LZ-Data-Collection-Tagging-Security]]（均涉及 ITOM 团队的 LZ 运维视角）
+- [[CTP-Topic-28-AWS-Tag-Validation-Tool]] ← complements ← [[CTP-Topic-10-AWS-Landing-Zone-LZ-Data-Collection-Tagging-Security]]（Topic 10 阐述标签用途，Topic 28 提供标签验证工具支撑）
 
 ## Contradictions
-- 暂无已知冲突
+- 与 [[CTP-Topic-7-SaaS-Landing-Zone-Design]] 存在表述角度差异：
+  - 冲突点：Topic 7 强调 LZ 的账号/OUs 顶层设计，Topic 10 强调标签驱动的运行时安全控制
+  - 当前观点：标签 + SCP 组合是 LZ 落地的关键执行层，标签策略与账号结构同等重要
+  - 对方观点：Topic 7 将账号架构置于更核心位置，标签为辅助属性
+  - 结论：两者视角互补而非矛盾——账号结构定义组织边界，标签驱动安全策略执行，共同构成完整的 LZ 治理体系

wiki/sources/ctp-topic-19-configuring-dns-within-aws-lzs.md

@@ -1,7 +1,13 @@
 ---
 title: "CTP Topic 19 Configuring DNS within AWS LZs"
 type: source
-tags: []
+tags:
+  - AWS
+  - DNS
+  - Landing-Zone
+  - CTP
+  - Route-53
+  - Multi-Account
 date: 2026-04-14
 ---
 
@@ -9,49 +15,39 @@ date: 2026-04-14
 - [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/08_Networking/ctp-topic-19-configuring-dns-within-aws-lzs.md]]
 
 ## Summary（用中文描述）
-- 核心主题：在 AWS Landing Zone 多账号环境中配置集中化 DNS 管理架构
-- 问题域：跨账号、跨云与本地数据中心（On-prem）之间的域名解析难题
-- 方法/机制：设立专用 DNS 账号集中管理 Route 53 私有托管区，通过 Route 53 Resolver Inbound/Outbound Endpoints 打通 AWS 与本地 DNS，AWS RAM 跨账号共享解析规则，Terraform 实现自动化部署
-- 结论/价值：集中化 DNS 管理优于分散式，是多账号 AWS 环境的标准最佳实践
+- 核心主题：在 AWS Landing Zone 多账号环境中配置集中化 DNS 管理架构，实现跨账号、跨云与本地数据中心（On-prem）之间的统一域名解析。
+- 问题域：如何在多账号 AWS 架构中避免私有托管区（PHZ）分散管理，解决从 AWS 访问本地资源、从本地访问 AWS 内部服务、以及账号间相互解析等场景。
+- 方法/机制：设立专门的 DNS 账号集中管理 Route 53 Resolver Rules；利用 Inbound/Outbound Endpoints 实现双向解析转发；通过 AWS RAM 跨账号共享解析规则；Terraform 模块自动化部署。
+- 结论/价值：集中化 DNS 账号模式优于分散式 PHZ，可简化路由规则维护、确保新账号上线即具备完整解析能力，适合 Frankfurt R&D、London SAS 等大规模落地场景。
 
 ## Key Claims（用中文描述）
-- 集中化 DNS 管理优于分散管理：应在 Landing Zone 中设立专门的 DNS 账号，而非在每个业务账号中分散创建私有托管区，便于统一维护路由规则和域名记录
-- Route 53 Resolver 是混合 DNS 架构的核心组件：Inbound Endpoints 接收来自本地数据中心的解析请求，Outbound Endpoints 将 AWS 内部请求转发至本地 DNS 服务器
-- AWS RAM 实现跨账号规则共享：通过 AWS Resource Access Manager 将 DNS 账号中定义的 Resolver Rules 共享给各个业务账号
-- 跨账号 VPC 与私有托管区关联必须先授权再关联：授权（Authorization）必须在关联（Association）之前完成
-- Terraform 是自动化部署 DNS 架构的核心工具：新业务 VPC 创建时自动完成规则共享与 VPC 关联，确保新账号上线即具备完整解析能力
+- 在 Landing Zone 中设立专门的 DNS 账号（InfoBlocks 账号），统一管理私有托管区和解析规则，优于在每个业务账号中分散创建 PHZ。
+- Route 53 Inbound Endpoint 接收来自本地数据中心的 DNS 解析请求；Outbound Endpoint 将 AWS 内部请求转发至本地 DNS 服务器。
+- 通过 AWS RAM 将 DNS 账号中的 Resolver Rules 共享给各业务账号，业务 VPC 无需单独创建规则即可使用。
+- 跨账号 VPC 与私有托管区关联时，必须先由 PHZ 拥有者执行"授权（Authorization）"，再由 VPC 拥有者执行"关联（Association）"。
+- 该架构高度依赖 Terraform 自动化部署，在创建业务 VPC 过程中通过预定义模块自动完成规则共享与 VPC 关联。
 
 ## Key Quotes
-> "我们推荐在 Landing Zone 中设立一个专门的 DNS 账号，所有私有托管区都集中在这里管理，而不是在每个业务账号中创建各自的托管区。" — Sankar Gopov，解释集中化 DNS 管理的优势
-> "Inbound Endpoints 用于接收来自本地数据中心的 DNS 查询请求；Outbound Endpoints 用于将 AWS 内部的 DNS 查询转发到本地 DNS 服务器。" — Sankar Gopov，Route 53 Resolver Endpoints 的双向作用
-> "跨账号关联时，必须先由托管区拥有者进行授权（Authorization），然后才能由 VPC 拥有者执行关联（Association）。" — Sankar Gopov，跨账号关联的必须步骤
+> "本次视频由 Sankar Gopov 主讲，核心内容围绕 AWS Landing Zone 环境下的 DNS 配置架构展开，特别是如何在多账号架构中实现集中化的 DNS 管理。" — 视频开篇背景介绍
 
 ## Key Concepts
-- [[Route 53 Resolver]]：AWS Route 53 的 DNS 解析组件，通过 Inbound/Outbound Endpoints 实现混合云 DNS 架构
-- [[Private Hosted Zone]]：AWS Route 53 的私有托管区，用于在指定 VPC 内部解析自定义域名，不对互联网开放
-- [[Route 53 Resolver Rules]]：解析规则，定义特定域名的解析路径（如将某后缀的域名转发至本地数据中心）
-- [[VPC Association Authorization]]：跨账号关联流程，PHZ 拥有者先授权，VPC 拥有者再执行关联
-- [[AWS RAM]]：Resource Access Manager，用于在组织内跨账号共享 Resolver Rules 等资源
-- [[Hybrid DNS Resolution]]：混合 DNS 解析，AWS VPC 与本地数据中心之间的跨环境域名解析机制
-- [[Terraform DNS Automation]]：使用 Terraform 自动化部署 DNS 架构的实践
+- [[Route-53-Resolver]]：AWS Route 53 的解析引擎，通过 Inbound/Outbound Endpoints 实现混合云 DNS 流量转发。
+- [[Private-Hosted-Zone]]：Route 53 私有托管区，在指定 VPC 内部解析自定义域名（如 `int-sas.local`），不暴露至互联网。
+- [[Resolver-Rules]]：解析规则，定义特定域名的解析路径（如匹配某后缀的域名需转发至本地数据中心特定 IP）。
+- [[AWS-RAM]]：Resource Access Manager，用于在 AWS Organization 内跨账号共享 Resolver Rules、Transit Gateway 等资源。
+- [[VPC-Association-Authorization]]：跨账号关联流程；VPC 与另一个账号的 PHZ 关联时必须先授权再关联。
+- [[AWS-Landing-Zone]]：多账号 AWS 环境规范，通过预配置的安全、网络和治理规则，为企业提供可扩展的基础设施框架。
 
 ## Key Entities
-- [[Sankar Gopov]]：本次视频讲师，AWS Landing Zone DNS 架构专家
-- [[AWS Landing Zone]]：AWS 多账号环境规范，是 DNS 架构的承载基础
+- [[SankarGopov]]：视频主讲人，来自 AWS/Cloud Transformation Programme，负责 DNS 架构设计与落地。
 
 ## Connections
-- [[ctp-topic-22-global-dns-service-offerings]] ← extends ← [[ctp-topic-19-configuring-dns-within-aws-lzs]]
-  - 两者同属 DNS 专题，后者（前文）讲企业级全局 DNS 服务架构（Infoblox + Route 53），后者（本文）聚焦 Landing Zone 内部的具体配置实施
-- [[ctp-topic-35-aws-landing-zone-design-refresher-saas-labs]] ← depends_on ← [[ctp-topic-19-configuring-dns-within-aws-lzs]]
-  - Landing Zone 顶层设计包含 DNS 账户的规划
-- [[ctp-topic-25-labs-landing-zone-overview-itom-teams]] ← relates_to ← [[ctp-topic-19-configuring-dns-within-aws-lzs]]
-  - Labs LZ 中 Core 账户托管 DNS 服务（Swimford.net）
-- [[ctp-topic-17-active-directory-services-in-gruntwork-aws-lzs]] ← depends_on ← [[ctp-topic-19-configuring-dns-within-aws-lzs]]
-  - AD 服务依赖 DNS 完成域名解析，int-sas.local 等域名的解析由 DNS 架构提供
+- [[AWS-Landing-Zone]] ← foundational ← [[CTP-Topic-19-DNS]]
+- [[Route-53-Resolver]] ← core_technology ← [[CTP-Topic-19-DNS]]
+- [[Terraform]] ← automation_tool ← [[CTP-Topic-19-DNS]]
+- [[AWS-RAM]] ← sharing_mechanism ← [[CTP-Topic-19-DNS]]
+- [[CTP-Topic-19-DNS]] ← related_topic ← [[CTP-Topic-35-AWS-Landing-Zone]]
+- [[CTP-Topic-19-DNS]] ← related_topic ← [[CTP-Topic-17-AD-Services]]
 
 ## Contradictions
-- 与 [[ctp-topic-22-global-dns-service-offerings]] 潜在视角差异：
-  - 冲突点：DNS 账号是否应包含公共托管区（Public Hosted Zone）
-  - 当前观点（Topic 19）：DNS 账号专注于私有托管区和 Route 53 Resolver 管理
-  - 对方观点（Topic 22）：Route 53 还需管理公共域名解析（Route 53 Hosted Zone + Route 53 Resolver）
-  - 注：两者可能适用于不同的环境（Topic 22 侧重 DNS 服务提供者的全局架构，Topic 19 侧重 Landing Zone 内部的落地配置）
+- 暂无已知冲突。本页内容与其他 Landing Zone 相关来源（如 CTP Topic 35）保持一致，均强调集中化基础设施账号的治理优势。

wiki/sources/ctp-topic-31-network-segregation-and-secure-access-to-the-new-aws-landing-zones.md

@@ -10,54 +10,52 @@ date: 2026-04-14
 ---
 
 ## Source File
-- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/08_Networking/ctp-topic-31-network-segregation-and-secure-access-to-the-new-aws-landing-zones.md]]
+- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/08_Networking/ctp-topic-31-network-segregation-and-secure-access-to-the-new-aws-landing-zones]]
 
 ## Summary（用中文描述）
-- 核心主题：AWS Landing Zone 网络隔离与安全远程访问方案
-- 问题域：内部网络（On-prem / VPN 用户）对 AWS Landing Zone 生产工作负载的未授权访问风险
-- 方法/机制：① 网络隔离——Checkpoint 防火墙实现 default-deny 的 SPI 模型，阻断内部网络对 AWS 网段的直接连通；② 安全访问——AWS Systems Manager (SSM) 替代 VPN，提供基于浏览器的安全远程连接
-- 结论/价值：该方案作为 SD-WAN 实施前的过渡方案，以更低成本和更快速度解决紧急安全风险；长期目标是 IaC 化以消除控制台访问
+- 核心主题：通过网络隔离与安全访问控制，解决企业内部系统直接访问 AWS Landing Zone 生产负载的安全与合规问题
+- 问题域：On-prem 系统和 VPN 用户因共享网络配置而能访问 AWS 生产区，存在安全合规风险
+- 方法/机制：
+  - **网络隔离**：使用 Checkpoint 防火墙建立检查点（SPI），默认拒绝通行，仅放行业务所需服务和网段
+  - **安全访问**：通过 AWS Systems Manager (SSM) 实现远程访问，用户假设 IAM Role 直连 EC2 上的 SSM Agent，无需 VPN
+- 结论/价值：SSM 方案作为 SD-WAN 落地前的临时方案，具有双因素认证、安全连接、零第三方依赖的优势；长期目标是 IaC 化以减少控制台访问
 
 ## Key Claims（用中文描述）
-- 内部网络与 VPN 用户因共享网络配置而可访问 AWS Landing Zone 生产工作负载，构成安全与合规风险
-- Checkpoint 防火墙启用 SPI（Security Policy Infrastructure）特性，默认 deny，仅放行必要服务和网段到 Landing Zone
-- AWS SSM 通过 IAM 角色假设 + SSM Agent 实现远程访问，无需 VPN，支持浏览器会话和 AWS CLI 两种模式
-- SSM 远程访问提供双因素认证保障，连接位于 AWS 网络内部，安全性高于传统 VPN
-- 当前方案定位于 SD-WAN 实施前的临时/备份方案，主要优势是降低成本和提升部署速度
-- 长期安全演进方向：IaC 化以减少控制台访问，break-glass 访问仅保留用于紧急场景
-- 当前方案聚焦网络隔离，不解决凭证被盗问题
+- On-prem 系统和 VPN 用户因共享网络配置可访问 AWS Landing Zone 生产区，造成安全合规风险
+- Checkpoint SPI 功能以默认拒绝（Default Deny）为基础，仅放行业务必需的服务和网络段
+- AWS SSM 提供基于浏览器的会话和 AWS CLI 远程访问，无需 VPN，消除对第三方管理的依赖
+- 用户通过假设 IAM Role 获得目标 EC2 上 SSM Agent 的访问权限，继承既有访问控制
+- SSM 方案安全性优势：双因素认证 + AWS 网络内安全连接
+- SSM 作为临时/备份方案，最终目标是 IaC + Break-glass 应急访问
+- 当前方案不解决凭证被盗风险，仅实现网络隔离
 
 ## Key Quotes
-> "The primary driver for this initiative is to address security concerns related to internal systems accessing production workloads in the new AWS landing zones." — 背景动机：内部系统对生产工作负载的访问安全风险
-
-> "The SPI features will be enabled with default deny enabled and allowances made for require services and network segments into the landing zones." — 核心机制：Checkpoint SPI 默认拒绝策略
-
-> "Authenticated users will assume roles granting access to the SSM agent on the target EC2 instance, leveraging existing access controls." — SSM 访问控制机制：基于 IAM 角色假设
-
-> "SSM gives users remote access via a browser based session." — SSM 核心价值：浏览器远程会话替代 VPN
+> "The primary driver for this initiative is to address security concerns related to internal systems accessing production workloads in the new AWS landing zones." — 问题背景
+> "SPI features will be enabled with default deny enabled and allowances made for require services and network segments into the landing zones." — Checkpoint 配置策略
+> "Authenticated users will assume roles granting access to the SSM agent on the target EC2 instance, leveraging existing access controls." — SSM 访问机制
+> "SSM gives users remote access via a browser based session." — SSM 核心价值
 
 ## Key Concepts
-- [[AWS-Landing-Zone]]：AWS 多账户架构框架，包含核心账户、基线账户、共享服务账户和产品账户
-- [[AWS-Systems-Manager-SSM]]：AWS 托管的远程管理服务，通过 SSM Agent 实现安全的无 VPN 远程访问，支持浏览器会话和 AWS CLI 模式
-- [[Network-Segregation]]：网络隔离策略，通过 Checkpoint 防火墙实现默认拒绝（default-deny），仅放行经授权的服务和网段通信
-- [[SPI-Security-Policy-Infrastructure]]：安全策略基础设施，在 Checkpoint 防火墙上强制执行网络分段，控制服务器间通信并阻断内部网络对 AWS 网段的直接访问
-- [[SD-WAN]]：软件定义广域网，组织的长期远程访问演进目标，当前 SSM 方案作为 SD-WAN 实施前的过渡方案
+- [[Network-Segmentation]]：通过防火墙检查点控制服务器间通信，阻止内部网络直接访问云端网段的安全策略
+- [[Zero-Trust-Access]]：基于 IAM Role 和 SSM Agent 的远程访问机制，替代传统 VPN 的零信任访问模式
+- [[AWS-Landing-Zone]]：AWS Landing Zone 的多账户架构与网络隔离设计原则
 
 ## Key Entities
-- [[Checkpoint]]：网络安全设备供应商，提供 Landing Zone 间网段隔离的防火墙能力，依赖 AWS 标签值动态配置访问策略
+- [[AWS-Landing-Zone]]：AWS 多账户 Landing Zone 架构，当前被 On-prem/VPN 用户共享网络配置所威胁
+- [[AWS-SSM]]：核心安全访问工具，提供浏览器会话和 CLI 两种远程访问方式
+- [[Checkpoint-Firewall]]：用于 SPI（Stateful Packet Inspection）网络隔离的防火墙，实现 Default Deny 策略
 
 ## Connections
-- [[ctp-topic-18-wide-area-networking-in-aws-cloud]] ← related_to ← [[ctp-topic-31-network-segregation-and-secure-access-to-the-new-aws-landing-zones]]
-  - 关联点：同属 AWS Landing Zone 网络知识体系，Topic 18 聚焦广域网架构（Transit Gateway / SD-WAN），Topic 31 聚焦网络隔离与安全访问
-- [[ctp-topic-25-labs-landing-zone-overview-itom-teams]] ← related_to ← [[ctp-topic-31-network-segregation-and-secure-access-to-the-new-aws-landing-zones]]
-  - 关联点：Topic 25 的 Labs LZ 运维视角涉及 VPN 远程访问需求，与 Topic 31 的 SSM 安全访问方案存在技术演进关系
-- [[ctp-topic-35-aws-landing-zone-design-refresher-saas-labs]] ← extends ← [[ctp-topic-31-network-segregation-and-secure-access-to-the-new-aws-landing-zones]]
-  - 关联点：Topic 35 明确提及"网络分段阻断对 SaaS 工作负载的直接连通性"，是 Topic 31 所描述方案的设计依据
+- [[AWS-Landing-Zone]] ← addresses_security_concerns ← [[Network-Segmentation]]
+- [[AWS-Landing-Zone]] ← secure_access ← [[AWS-SSM]]
+- [[AWS-SSM]] ← temporary_solution_for ← [[SD-WAN]]
+- [[Checkpoint-Firewall]] ← enforces ← [[Network-Segmentation]]
 
 ## Contradictions
-- 与 [[ctp-topic-18-wide-area-networking-in-aws-cloud]] 存在视角差异：
-  - 冲突点：Topic 18 强调广域网连通性（Transit Gateway Peering / SD-WAN / Pulse VPN 迁移至 Prisma Access），关注如何打通网络
-  - Topic 31 视角：网络隔离的首要目标是阻断内部网络对 AWS 的直接访问，关注如何限制连通性
-  - 对方观点：Topic 18 的演进路线中，Prisma Access (SASE) 将提供更安全的远程接入方案
-  - 当前观点：Topic 31 主张 SSM 作为过渡方案，在 SD-WAN 实施前优先解决网络安全隔离问题
-  - 调和建议：两者互补——Topic 31 解决内部网络隔离的短期安全问题，Topic 18 规划长期广域网演进路径（SD-WAN / SASE）
+- 与传统 VPN 接入方案存在替代关系：
+  - 冲突点：VPN 提供通用远程接入，但无法精细控制到单个 AWS 网段
+  - 当前观点：SSM 取代 VPN 作为 AWS Landing Zone 的安全访问手段
+  - 对方观点：VPN 仍是部分场景（通用办公网络）的必要访问方式
+- 与 [[SD-WAN]] 的关系：
+  - 当前观点：SSM 是 SD-WAN 落地前的临时方案
+  - 未来观点：SD-WAN 部署后将从网络层解决跨区域安全互联问题

wiki/sources/ctp-topic-36-sendgrid-as-an-email-service.md

@@ -11,7 +11,7 @@ date: 2026-04-14
 ---
 
 ## Source File
-- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/08_Networking/ctp-topic-36-sendgrid-as-an-email-service.md]]
+- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/08_Networking/ctp-topic-36-sendgrid-as-an-email-service.md]]
 
 ## Summary（用中文描述）
 - 核心主题：Cloud Transformation Program（CTP）正式采用 SendGrid 作为标准邮件服务，取代原有的语义消息网关和 SES 方案；同时更新了 Cyber Suite 安全加密标准。

wiki/sources/ctp-topic-4-using-agile-to-run-the-cloud-transformation-program.md

@@ -1,47 +1,48 @@
 ---
 title: "CTP Topic 4 Using Agile to Run the Cloud Transformation Programme"
 type: source
-tags: []
-sources: []
-last_updated: 2026-04-24
+tags:
+  - Agile
+  - Cloud-Transformation
+  - CTP
+  - Scrum
+  - Kanban
+date: 2026-04-14
 ---
 
 ## Source File
-- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/ctp-topic-4-using-agile-to-run-the-cloud-transformation-program.md]]
+- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/ctp-topic-4-using-agile-to-run-the-cloud-transformation-program]]
 
 ## Summary（用中文描述）
-- 核心主题：云转型计划（Cloud Transformation Programme）中敏捷实践的落地经验
-- 问题域：大型企业云迁移项目如何选择和调整敏捷框架
-- 方法/机制：Scrum → Kanban 的框架演进；Microsoft Planner 作为看板工具；每日站会 + 回顾会议保留 Scrum 仪式
-- 结论/价值：Scrum 的固定 Sprint 节奏不适合快速变化的云转型项目，Kanban 持续流动 + 固定仪式是更优的混合方案
+- 核心主题：云转型项目中的敏捷框架实践——从 Scrum 到 Kanban 的演进过程
+- 问题域：大型企业云转型项目中敏捷落地的实际挑战，包括迭代周期限制、变更管理、团队协作与持续交付
+- 方法/机制：初期采用 Scrum 两周冲刺（含产品待办列表、Sprint 规划、回顾、评审、每日站会）；因无法应对频繁变更而转向 Kanban 持续流模式；当前为混合模式（Kanban 为主，保留 Scrum 仪式）。使用 Microsoft Planner 看板管理任务（backlog / to do / in progress / program key decisions / icebox 五列）
+- 结论/价值：Kanban 适合持续变更的云转型项目，允许随时调整优先级；Scrum 仪式（每日站会、回顾会）仍有保留价值，有助于快速反馈和团队文化改进
 
 ## Key Claims（用中文描述）
-- 云转型团队从 Scrum（两周 Sprint）转向 Kanban，因为 Sprint 期间不允许变更，无法应对项目中的频繁变化
-- 混合框架（Kanban 为主 + 保留 Scrum 仪式）是当前最优方案
-- 每日站会应简短（15-30 分钟），围绕 Planner 看板回答三个问题：昨天完成什么、今天做什么、有什么阻碍
-- 回顾会议是快速反馈循环的核心，通过行动项（带负责人）驱动团队持续改进
-- Microsoft Planner 看板列：Backlog → To Do → In Progress → Program Key Decisions → Icebox
-- 每张任务卡必须指定单一负责人，即使多人协作；明确角色（如 oversight）；链接依赖卡；使用优先级和截止日期
+- Scrum 的核心局限：两周冲刺周期内不允许中途变更需求，导致云转型这类频繁变化的敏捷项目难以适应
+- Kanban 的核心优势：支持随时变更优先级和范围，专注于持续交付而非批量发布
+- 混合框架的价值：保留每日站会和回顾会（Scrum 仪式），同时采用 Kanban 的持续流工作方式
+- Microsoft Planner 作为任务管理工具：集中管理需求、明确定义任务Owner、链接依赖任务、使用优先级和截止日期
+- 敏捷的本质：通过快速反馈循环持续改进产品和开发文化
 
 ## Key Quotes
-> "The big problem with Scrum, in my opinion, is that you can't make changes throughout the sprints, we are not advised to." — Heather Norris，解释为何从 Scrum 转向 Kanban
-
-> "Agile is all about getting that rapid feedback to make the product and make the, you know, the development culture better." — Heather Norris，阐述敏捷的核心价值
+> "The big problem with Scrum, in my opinion, is that you can't make changes throughout the sprints, we are not advised to." — Heather Norris，阐述 Scrum 在云转型项目中的局限性
+> "Agile is all about getting that rapid feedback to make the product and make the development culture better." — Heather Norris，阐述敏捷的核心价值
 
 ## Key Concepts
-- [[Scrum]]：两周一迭代的敏捷框架，包含 Product Backlog、Sprint Planning、Daily Scrum、Sprint Review、Sprint Retrospective；因 Sprint 期间禁止变更而被云转型团队放弃
-- [[Kanban]]：持续流动的敏捷框架，允许随时调整优先级，无固定 Sprint 边界；适合变化频繁的云转型项目
-- [[Agile Ceremonies]]：Scrum 的固定仪式——Sprint Planning（冲刺规划）、Daily Stand-up（每日站会）、Sprint Review（冲刺评审）、Retrospective（回顾会议）；云转型团队保留站会和回顾会议
-- [[Continuous Delivery]]：持续交付，Kanban 的核心优势，无需等待 Sprint 结束即可发布
-- [[Microsoft Planner Board]]：微软看板工具，云转型团队的项目管理平台，支持卡片管理、依赖链接、优先级设置
+- [[Scrum]]：一种敏捷框架，以固定周期的 Sprint 为核心，包含产品待办列表、Sprint 规划、每日站会、评审和回顾会议
+- [[Kanban]]：一种可视化工作流管理方法，支持持续交付，允许随时调整优先级和范围，不受固定迭代周期限制
+- [[Scrum-Kanban混合框架]]：保留 Scrum 仪式（每日站会、回顾会）的同时，采用 Kanban 的持续流工作方式
+- [[Microsoft Planner]]：微软的任务管理工具，采用看板结构管理团队工作
 
 ## Key Entities
-- [[Heather Norris]]：云转型计划项目经理，主讲本次分享，介绍敏捷方法论实践
-- [[Microsoft Planner]]：团队使用的项目管理看板工具
+- [[Heather Norris]]：云转型项目经理，分享了敏捷方法论在项目中的实际落地经验
 
 ## Connections
-- [[ctp-topic-57-product-backlog-managing-demand]] ← related_to ← [[ctp-topic-4-using-agile-to-run-the-cloud-transformation-program]]
-- [[ctp-topic-30-managing-change]] ← extends ← [[ctp-topic-4-using-agile-to-run-the-cloud-transformation-program]]
+- [[CTP Topic 57 Product backlog managing demand]] ← relates_to ← [[Scrum]]
+- [[CTP Topic 3 Deploy and maintain infrastructure]] ← extends ← [[Kanban]]
+- [[CTP Topic 41 NFR's and Error Budgets]] ← relates_to ← [[敏捷文化]]
 
 ## Contradictions
-- 无已知冲突
+- （暂无发现与其他来源的内容冲突）

wiki/sources/ctp-topic-43-vmware-cloud-on-aws.md

@@ -36,19 +36,20 @@ date: 2026-04-14
 - [[SDDC]]：软件定义数据中心，VMC on AWS 通过 vCenter 进行管理的核心架构单元
 - [[HCX]]：Hybrid Cloud Extension，支持任意 vSphere 环境之间的双向工作负载迁移
 - [[Stretched-Cluster]]：跨可用区的拉伸集群，提供跨 AZ 的高可用和灾难恢复能力
-- [[TCO]]：总拥有成本，云经济学团队用于评估迁移成本效益的核心指标
+- [[TCO]]：总拥有成本，云经济学团队用于评估迁移成本效益的核心指标（VMC on AWS 相比常规云节省 27%）
 
 ## Key Entities
 - [[VMware]]：企业级虚拟化和云计算软件提供商，与 AWS 合作开发 VMC on AWS
 - [[AWS]]：Amazon Web Services，提供 VMC on AWS 的底层裸机服务器基础设施（i3.metal/i3en.metal）
-- Brian Reeves：VMware 演讲者，讨论 VMC on AWS 的经济学效益
-- Michael Riley：VMware 演讲者
-- Mike Armstrong：VMware 演讲者
-- Mike O'Reilly：VMware Staff Cloud Solutions Architect，主讲 VMC on AWS 技术架构
+- [[BrianReeves]]：VMware 演讲者，讨论 VMC on AWS 的经济学效益
+- [[MichaelRiley]]：VMware 演讲者
+- [[MikeArmstrong]]：VMware 演讲者
+- [[MikeOReily]]：VMware Staff Cloud Solutions Architect，主讲 VMC on AWS 技术架构
 
 ## Connections
 - [[ctp-topic-7-saas-landing-zone-design]] ← extends ← [[ctp-topic-43-vmware-cloud-on-aws]]（两者均涉及 AWS 基础设施上的企业工作负载部署）
 - [[ctp-topic-35-aws-landing-zone-design-refresher-saas-labs]] ← related_to ← [[ctp-topic-43-vmware-cloud-on-aws]]（混合云是 Landing Zone 设计的重要扩展方向）
+- [[ctp-topic-69-best-practices-for-migrating-on-premises-iod-virtual-machines-to-vm]] ← extends ← [[ctp-topic-43-vmware-cloud-on-aws]]（Topic 43 介绍 VMC on AWS 概述，Topic 69 深入迁移最佳实践）
 
 ## Contradictions
 - 与 [[ctp-topic-53-why-bother-with-cloud]] 潜在冲突：

wiki/sources/ctp-topic-45-automatic-ip-address-allocation-with-ipam.md

@@ -1,5 +1,5 @@
 ---
-title: "CTP Topic 45 Automatic IP address allocation with IPAM"
+title: "CTP Topic 45 Automatic IP Address Allocation with IPAM"
 type: source
 tags:
   - AWS
@@ -7,46 +7,50 @@ tags:
   - Networking
   - CTP
   - Infoblox
-  - VPC
-  - Terragrunt
-date: 2026-04-14
+date: 2026-04-24
 ---
 
 ## Source File
 - [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/08_Networking/ctp-topic-45-automatic-ip-address-allocation-with-ipam.md]]
 
 ## Summary（用中文描述）
-- 核心主题：使用 Infoblox NIOS 实现 AWS VPC 自动化 IP 地址分配，替代传统手工电子表格管理方式
-- 问题域：IP 地址管理效率低下（手工请求→网络团队计算CIDR→手工填表→人工配置YAML），新增VPC需要反复与网络团队交接
-- 方法/机制：Infoblox NIOS IPAM 系统自动查询下一个可用 IP 地址块，按需自动审批（≤/24自动，>/24需网络团队审批），Terragrunt YAML 配置文件不再包含硬编码 IP，改由 NIOS 动态注入
-- 结论/价值：实现"创建 VPC 无需网络团队参与"的完全自动化目标，消除 Excel 表格管理，建立单一可信数据源，向后兼容旧 YAML 配置
+- 核心主题：使用 Infoblox NIOS IPAM 平台实现 VPC IP 地址分配的完全自动化，替代传统手工 Excel 管理模式。
+- 问题域：企业多账号 AWS 环境中，IP 地址手工分配效率低、易出错，且需频繁与网络团队交接。
+- 方法/机制：声明式 YAML 配置文件替代手工 CIDR 规划；Infoblox NIOS 自动查询下一可用 IP 地址块；/24 及以上触发审批流程；支持 VPC 销毁时自动清理 IPAM 记录。
+- 结论/价值：**用户无需再向网络团队申请 IP 地址**，系统自动完成规划、分配和回收，实现 IP 地址管理的单一可信数据源。
 
 ## Key Claims（用中文描述）
-- Infoblox NIOS 通过 API 自动分配下一个可用 IP 地址块，替代人工计算 CIDR 范围和手动更新电子表格
-- 当所需网络地址 ≤/24 时，VPC 模块自动运行，无需人工干预
-- 当所需网络地址 >/24 时，系统自动触发网络团队审批流程，而非直接拒绝
-- 新 YAML 配置文件中不再包含 CIDR 子网 IP 地址，仅声明期望的子网大小（如 /22）和区域级父 CIDR 常量
-- VPC 名称被纳入 YAML 文件，支持一次性配置多个 VPC
-- 销毁 VPC 时自动从 IPAM Grid 中清除所有相关条目，支持撤销保护（Terragrunt.hcl 需特殊 flag 防止误删）
-- 新系统向后兼容现有 VPC 配置，旧 YAML 文件继续工作
+- IPAM 通过 Infoblox NIOS 自动化 IP 地址分配，消除手工 Excel 管理，将 IP 地址规划效率提升数倍。
+- 新的 YAML 配置文件仅声明业务联系人、工程联系人和所需子网大小（而非硬编码 CIDR），系统自动从 Infoblox 获取下一可用 IP 地址块。
+- /24 及更小子网需网络团队审批，/22 及更大子网自动批准（参见 [[CIDR-审批流程]]）。
+- VPC 销毁时自动从 Infoblox Grid 移除所有相关 IP 记录，支持完整生命周期管理。
+- YAML 支持多 VPC 配置和可用区 ID（AZ ID）指定，兼容性强。
+- 系统向后兼容：使用旧 YAML 文件的现有 VPC 配置继续正常工作。
 
 ## Key Quotes
-> "Managing the IP address in a spreadsheet takes time and it's not a good approach." — 当前电子表格管理方式的低效痛点
-> "We are not asking for IP address from the network team." — 新系统的核心价值：消除网络团队交接
-> "The goal is for any new VPC that we don't have to engage the network team every time we want to create a VPC with the subnets." — 自动化愿景
+> "Managing the IP address in a spreadsheet takes time and it's not a good approach." — 传统 Excel 管理 IP 地址的低效性
+> "We are not asking for IP address from the network team." — IPAM 自动化的核心价值——彻底消除与网络团队的手工交接
 
 ## Key Concepts
-- [[IPAM（IP Address Management）]]：IP 地址管理系统的核心概念，NIOS 提供集中化管理、控制、监控和分配 IP 地址空间的能力
-- [[Infoblox-NIOS]]：Infoblox NIOS 是 IPAM 功能的核心实现，作为分布式 Grid 框架的扩展，集成 DNS/DHCP，提供统一管理控制台
-- [[VPC-自动化供给]]：通过 Terragrunt YAML 配置文件声明式定义 VPC 需求，由 NIOS 自动分配 IP 地址，无需手工配置
+- [[IPAM]]：IP Address Management，企业级 IP 地址管理平台，本视频展示 Infoblox NIOS 作为 IPAM 引擎与 AWS VPC 供给的集成。
+- [[Infoblox-NIOS]]：Infoblox 的核心网络控制平面，提供 DNS、DHCP 和 IP 地址管理功能，支持可扩展属性（Extensible Attributes）用于存储元数据。
+- [[VPC-自动化供给]]：通过声明式 YAML 配置文件自动完成 VPC 创建，IP 地址分配完全自动化。
+- [[CIDR-审批流程]]：基于 CIDR 大小的差异化审批策略——/24 及以下需网络团队审批，/22 及更大自动批准。
+- [[Infoblox-Grid]]：Infoblox 的分布式网格架构，作为全局唯一的 IP 地址数据源。
+- [[Availability-Zone-ID]]：AWS 可用区标识符（az-id），用于避免多账号环境中可用区名称（az-name）不一致问题。
 
 ## Key Entities
-- [[Grid-Master]]：Infoblox Grid 架构中的核心节点，管理 API 调用和各 AWS 云账户的 IP 地址分配
+- [[Pushka]]（Principal SRE）：IPAM 与 VPC 自动化方案的发起人和演示者，Topic 45 主讲人。
+- [[Infoblox]]：IPAM 供应商，提供 NIOS 平台及 Grid 架构。
+- [[AWS-Landing-Zone]]：本方案的实施背景——企业级多账号 AWS 环境。
 
 ## Connections
-- [[ctp-topic-61-workload-vpc-provision-with-ipam-automation]] ← relates_to ← 本页：均涉及 VPC 供给与 IPAM 自动化的实践
-- [[ctp-topic-25-labs-landing-zone-overview-itom-teams]] ← depends_on ← 本页：Labs Landing Zone 的 VPC 供给依赖 IPAM 自动分配
-- [[ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security]] ← related_to ← 本页：均涉及标签驱动的 AWS 基础设施自动化
+- [[ctp-topic-61-workload-vpc-provision-with-ipam-automation]] ← extends ← [[ctp-topic-45-automatic-ip-address-allocation-with-ipam]]
+  - Topic 45 介绍 IPAM 自动分配机制；Topic 61 展示该机制在 Workload VPC 供给中的完整应用。
+- [[ctp-topic-22-global-dns-service-offerings]] ← shares_infra ← [[Infoblox]]
+  - Infoblox 同时支撑 DNS Anycast 和 IPAM 服务，是网络层多服务的统一基础设施。
+- [[ctp-topic-31-network-segregation-and-secure-access]] ← depends_on ← [[VPC-自动化供给]]
+  - VPC 自动化供给是网络分段和安全访问策略的基础前提。
 
 ## Contradictions
-- 无已知冲突内容
+- 无已知冲突内容。

wiki/sources/ctp-topic-61-workload-vpc-provision-with-ipam-automation.md

@@ -1,5 +1,5 @@
 ---
-title: "CTP Topic 61 Workload VPC provision with IPAM Automation"
+title: "CTP Topic 61 Workload VPC Provision with IPAM Automation"
 type: source
 tags:
   - AWS
@@ -7,52 +7,46 @@ tags:
   - IPAM
   - Automation
   - CTP
-  - Infoblox
-date: 2026-04-24
+date: 2026-04-14
 ---
 
 ## Source File
 - [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/08_Networking/ctp-topic-61-workload-vpc-provision-with-ipam-automation.md]]
 
 ## Summary（用中文描述）
-- 核心主题：IPAM（IP 地址管理）与 Workload VPC 自动化供给的完整集成方案，包括近期功能增强。
-- 问题域：企业多账号 AWS 环境中，如何在不依赖网络团队手工介入的情况下，自动完成 VPC 的 IP 地址规划与供给。
-- 方法/机制：使用 Infoblox Grid 作为核心 IPAM 引擎，通过声明式 YAML 配置文件触发自动化供给流程；/22 及更大 CIDR 自动审批，更小 CIDR 触发邮件审批流程；Availability Zone ID（而非 AZ Name）避免跨区域不一致；多 VPC 批量供给和非路由 IP 地址（如 10.2.0.0/16）支持。
-- 结论/价值：**"只需把信息放到正确位置，一切自动完成。"** 用户只需声明业务联系人和父 CIDR，无需关心 IP 地址分配细节；Infoblox Grid 作为唯一可信数据源，防止 IP 地址重叠。
+- 核心主题：基于 IPAM（Infoblox Grid）的 Workload VPC 自动化供给流程，包括审批机制和增强功能。
+- 问题域：企业 AWS 多账号环境中，VPC 供给需要协调网络团队手动分配 IP 地址，流程繁琐且易出错。
+- 方法/机制：声明式 IPAM YAML 文件驱动自动化供给；Infoblox Grid 作为 IP 地址单一可信数据源；CIDR ≥ /22 自动通过，< /22 触发网络团队审批；使用 AZ ID 而非 AZ Name 确保跨区域一致性。
+- 结论/价值：**用户只需在正确位置填入信息，VPC 供给流程全自动完成**，IP 地址冲突由 Infoblox 阻止，支持多 VPC 同时供给和邮件通知。
 
 ## Key Claims（用中文描述）
-- IPAM 通过 Infoblox Grid 自动管理 IP 地址，消除手工操作，显著降低配置错误率。
-- 工作负载 VPC 供给完全自动化，YAML 文件仅声明业务联系人、工程联系人和父 CIDR，不再包含硬编码 IP 地址。
-- CIDR 块大小决定审批流程：/22 或更大自动批准，更小（如 /24）需提交理由并由网络团队审批。
-- Infoblox Grid 作为全局唯一 IP 地址数据源，防止多账号环境中的 IP 地址重叠冲突。
-- 使用 AZ ID（可用区标识符）而非 AZ Name（可用区名称）避免不同 AWS 账户对同一物理位置命名不一致的问题。
-- 邮件通知机制覆盖用户和网络团队，全程透明可追溯。
-- Infoblox 架构包含位于休斯顿数据中心的主数据库，以及冗余的 DNS、NTP 和 DHCP 服务。
+- IPAM（Infoblox Grid）通过自动化 IP 地址管理，消除手工干预，显著降低错误率。
+- 工作负载 VPC 自动化流程使用声明式 YAML 文件指定业务联系人、工程联系人和父 CIDR，无需手工规划 IP 地址。
+- CIDR 前缀 ≥ /22 时自动通过审批；< /22 时必须由网络团队审核理由后才能继续供给。
+- 使用 Availability Zone ID（az id）替代 Availability Zone Name（az name），避免不同区域命名不一致导致的跨区域部署问题。
+- Infoblox Grid 作为 IP 地址中央管理平台，防止 IP 地址重叠，并维护所有已配置 IP 的记录供查询。
+- 当前增强功能包括：多 VPC 批量供给、邮件通知、额外 CIDR 块支持、非可路由 IP 地址支持（如 10.2.0.0/16）。
+- VPC 销毁时，Infoblox 自动清理对应 IP 记录，保持 IP 地址池的实时同步。
 
 ## Key Quotes
-> "We don't need to worry about IP address. If it's beyond IP address is 22 or greater, then only we need to take the approval." — Pushka，IPAM 自动化审批阈值说明
+> "We don't need to worry about IP address. If it's beyond IP address is 22 or greater, then only we need to take the approval." — Pushka (Principal SRE)，说明 IPAM 自动化大幅简化了 IP 地址管理流程
 
-> "So we just need to put the information at the right place and everything will work." — Pushka，用户只需提供正确信息，IPAM 自动完成其余工作
+> "So we just need to put the information at the right place and everything will work." — Pushka，强调用户只需提供业务信息，底层流程全自动化
 
 ## Key Concepts
-- [[IPAM（IP Address Management）]]：企业级 IP 地址管理自动化平台，通过声明式配置替代手工分配。本视频展示了 IPAM 与 AWS VPC 供给的深度集成。
-- [[Infoblox-Grid]]：核心 IPAM 引擎，包含容器、IP地址及可扩展属性（元数据，如 owner、company、status），维护全局唯一 IP 地址记录。
-- [[VPC-自动化供给]]：通过 YAML 配置文件声明业务参数，自动触发 VPC 创建流程，无需网络团队手工介入。
-- [[CIDR-审批流程]]：/22 及更大 CIDR 自动批准；/22 以下需提交理由经网络团队审批后供给。
-- [[Availability-Zone-ID]]：AWS 可用区标识符（az-id），用于避免多账号环境中 AZ 名称（az-name）不一致问题。
+- [[IPAM]]：IP Address Management，即 IP 地址管理。本视频聚焦 Infoblox NIOS IPAM 平台，用于 AWS VPC 环境中的自动化 IP 地址分配和回收。
+- [[Infoblox Grid]]：企业级 IPAM 解决方案，作为 IP 地址的单一可信数据源，支持容器化部署和可扩展属性（元数据）管理。
+- [[Workload VPC]]：承载业务工作负载的 AWS VPC，与基础设施 VPC 分离，由 IPAM 自动化供给。
+- [[CIDR]]：Classless Inter-Domain Routing，用于 VPC IP 地址块划分。本视频中 /22 为审批阈值。
+- [[Availability Zone ID]]：AWS AZ 的唯一标识符（如 use1-az1），优于 AZ Name（如 us-east-1a），因为同一 AZ Name 在不同账户可能映射到不同物理位置。
 
 ## Key Entities
-- [[Pushka]]（Principal SRE）：IPAM 与 VPC 自动化方案的发起人和演示者，Topic 61 主讲人。
-- [[Infoblox]]：IPAM 供应商，提供 Grid 架构及 NIOS 平台，负责管理所有账号的 IP 地址分配记录。
-- [[AWS-Landing-Zone]]：本方案的实施背景——企业级多账号 AWS 环境，IPAM 作为 LZ 网络层的核心组件。
+- [[Pushka]]：Principal SRE，本视频主讲人，介绍 IPAM 与 Workload VPC 自动化供给方案。
+- [[Infoblox]]：IPAM 软件供应商，Houston 数据中心部署主数据库，提供 DNS、NTP、DHCP 冗余服务。
 
 ## Connections
-- [[ctp-topic-45-automatic-ip-address-allocation-with-ipam]] ← extends ← [[ctp-topic-61-workload-vpc-provision-with-ipam-automation]]
-  - Topic 45 介绍 IPAM 自动分配机制；Topic 61 展示该机制在 Workload VPC 供给中的完整应用。
-- [[ctp-topic-22-global-dns-service-offerings]] ← shares_infra ← [[Infoblox-Grid]]
-  - Infoblox 同时支撑 DNS Anycast 和 IPAM 服务，是网络层多服务的统一基础设施。
-- [[ctp-topic-31-network-segregation-and-secure-access]] ← depends_on ← [[VPC-自动化供给]]
-  - VPC 自动化供给是网络分段和安全访问策略的基础前提。
+- [[CTP Topic 45 Automatic IP Address Allocation with IPAM]] ← extends ← [[CTP Topic 61 Workload VPC Provision with IPAM Automation]]
+  - 说明：Topic 45 介绍 IPAM 自动分配 IP 地址的核心机制；Topic 61 聚焦于 Workload VPC 层级的完整自动化供给流程，包含审批机制和增强功能。
 
 ## Contradictions
-- 无已知冲突内容。
+- 暂未发现与现有 Wiki 页面的内容冲突。

wiki/sources/ctp-topic-65-tracing-the-value-delivered-in-cloud-transformation.md

@@ -5,52 +5,54 @@ tags:
   - Value-Tracing
   - Cloud-Transformation
   - CTP
+  - Lean
+  - WSJF
 date: 2026-04-14
 ---
 
 ## Source File
-- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/ctp-topic-65-tracing-the-value-delivered-in-cloud-transformation.md]]
+- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/ctp-topic-65-tracing-the-value-delivered-in-cloud-transformation.md]]
 
 ## Summary（用中文描述）
-- 核心主题：云转型中的价值交付量化框架与工作优先级排序方法
-- 问题域：如何系统性地衡量、捕获和优先排序云转型工作中的业务价值
-- 方法/机制：①定义过程（Process）和价值流（Value Stream）概念；②建立全局收益框架（财务、生产力、质量、体验四维度）；③使用加权最短作业优先（WSJF）方法对工作进行经济性排序；④在功能级别拆解价值归属
-- 结论/价值：云转型工作应以"最小投入尽早交付最大价值"为原则，通过量化收益和成本延迟比来优化工作排序，实现经济收益最大化
+- 核心主题：云转型计划（CTP）中的价值交付追踪方法论——如何量化、分解和优先排序云转型工作的业务价值。
+- 问题域：云转型项目如何衡量和证明业务价值；如何让产品团队和需求经理对齐价值期望；如何用经济驱动的方式排序工作。
+- 方法/机制：
+  - 区分 Process（过程）、Value（价值）、Value Stream（价值流）三个层次；
+  - 将业务价值分解为财务、生产力、质量、体验四个维度；
+  - 使用 WSJF（Weighted Shortest Job First，加权最短作业优先）公式：`Cost of Delay / Job Size` 决定工作优先级；
+  - 功能级价值分解策略：单功能归因、均匀分摊、非均匀分摊（按覆盖度/影响力/工时）。
+- 结论/价值：通过结构化价值捕获框架（年收入增长 + 成本降低 + 风险改善 + SOM），以最小投入尽早交付最大价值，循环学习调优。
 
 ## Key Claims（用中文描述）
-- 过程（Process）是由输入（数据、资源、时间、资金、专业知识）驱动的系统性步骤，将输入转化为产出和成果，成果分为硬性（时间、成本、质量）和软性（健康、安全）
-- 价值（Value）由客户决定，体现为公平回报或等价商品；Lean 识别三类活动：增值活动、价值赋能活动、浪费
-- 价值流（Value Stream）是向客户交付产品或服务的系列活动，分为运营价值流（OVS，面向客户）和开发价值流（DVS，内部产品）
-- 收益捕获需要全局框架，涵盖财务、生产力、质量和体验四个维度，聚焦收入增长、成本降低、风险改善和服务可获得市场规模（SOM）
-- 加权最短作业优先（WSJF）方法通过"延迟成本/作业规模"比值对工作排序，实现最大经济收益
-- 延迟成本 = 业务价值 + 时间紧迫性 + 风险与机会
+- 过程（Process）是一组有序步骤，将输入（数据、资源、时间、资金、知识）转化为输出和结果，结果分为硬性（时间、成本、质量）和软性（健康、安全）两类。
+- 价值由客户定义，是事物的货币价值，涉及公平回报或等价商品；Lean 将活动分为三类：增值活动（Value-Adding）、价值赋能活动（Value-Enabling）、浪费（Waste）。
+- 价值流（Value Stream）是一组为客户交付产品或服务的活动集合；Scaled Agile 定义了运营价值流（OVS，面向客户）和开发价值流（DVS，内部产品）两类。
+- 价值捕获需要综合框架，涵盖财务、生产力、质量和体验四个维度，重点关注收入增长、成本降低、风险改善和服务可获得市场规模（SOM）。
+- WSJF 优先级排序公式：`CoD（业务价值 + 时间紧迫性 + 风险与机会）/ 工作规模`，最大化经济收益地排列工作顺序。
+- 功能级价值分解的三种方式：单功能归因全部价值、按功能均匀分摊、按覆盖度/影响力/工时等标准非均匀分摊。
 
 ## Key Quotes
-> "What we want to do is deliver the maximum value early back into the business for the least amount of effort." — CTP Topic 65 核心目标
-> "A simple way of thinking of an outcome is that there's usually going to be a desirable change in some important attribute or indicator." — 成果的定义
-> "For each demand, the demand manager captures these five things from the product team. Financial figures should be annualized." — 需求管理流程
-> "The weighted shortest job first method prioritizes work based on cost of delay divided by size of job." — WSJF 优先级排序公式
+> "Value is defined as the monetary worth of something, determined by the customer, involving a fair return or equivalent goods." — 价值的核心定义：由客户决定货币价值
+
+> "What we want to do is deliver the maximum value early back into the business for the least amount of effort." — 云转型工作的核心目标：以最小投入尽早交付最大价值
+
+> "A simple way of thinking of an outcome is that there's usually going to be a desirable change in some important attribute or indicator." — 理解结果（Outcome）的简单方式：某个重要属性或指标的可期望变化
 
 ## Key Concepts
-- [[Process]]：由输入驱动的系统性步骤，将输入转化为产出和成果
-- [[Value]]：由客户决定的货币价值，体现为公平回报
-- [[Value-Stream]]：向客户交付产品或服务的系列活动，包含 OVS（运营价值流）和 DVS（开发价值流）
-- [[Value-Adding]]：Lean 中的增值活动类型
-- [[Waste]]：Lean 中的浪费活动类型
-- [[Benefits-Quantification]]：财务、生产力、质量、体验四维度收益量化框架
-- [[Cost-of-Delay]]：延迟成本 = 业务价值 + 时间紧迫性 + 风险与机会
-- [[WSJF]]：Weighted Shortest Job First，通过 Cost of Delay / Size of Job 比值排序工作
-- [[SOM]]：Serviceable Obtainable Market，可服务可获得市场规模
-- [[Feature-Level-Value-Breakdown]]：在功能级别拆解和分配价值的方法
+- [[Value Stream]]：一组为客户交付产品或服务的活动集合；OVS 面向客户，DVS 面向内部产品
+- [[Weighted Shortest Job First (WSJF)]]：优先级排序公式，`CoD / Job Size`，最大化经济收益
+- [[Cost of Delay (CoD)]]：延迟成本 = 业务价值 + 时间紧迫性 + 风险与机会
+- [[Process]]：将输入转化为输出和结果的有序步骤集合，触发于事件（如月末、冲刺规划）
+- [[Value-Adding Activity]]：Lean 中直接为客户创造价值的活动
+- [[Serviceable Obtainable Market (SOM)]]：服务可获得市场规模，用于评估市场机会
 
 ## Key Entities
-- [[CTP]]：Cloud Transformation Programme，云转型计划（本视频来源项目）
-- [[Scaled-Agile]]：SAFe 框架定义了 OVS 和 DVS 概念（本视频引用）
+- [[Cloud Transformation Programme (CTP)]]：OpenText 的云转型计划，主题来源
 
 ## Connections
-- [[ctp-topic-4-using-agile-to-run-the-cloud-transformation-program]] ← relates_to ← [[ctp-topic-65-tracing-the-value-delivered-in-cloud-transformation]]（均涉及敏捷方法管理云转型）
-- [[ctp-topic-20-program-demand-process-flow-and-poc-onboarding]] ← extends ← [[ctp-topic-65-tracing-the-value-delivered-in-cloud-transformation]]（需求流程与价值量化协同）
-- [[ctp-topic-30-managing-change]] ← relates_to ← [[ctp-topic-65-tracing-the-value-delivered-in-cloud-transformation]]（变更管理与价值交付的关系）
+- [[CTP Topic 53 Why bother with Cloud]] ← context ← [[CTP Topic 65 Tracing the Value Delivered in Cloud Transformation]]（CTP 53 回答"为何要上云"，本主题回答"如何衡量云转型价值"）
+- [[CTP Topic 57 Product backlog managing demand]] ← extends ← [[CTP Topic 65 Tracing the Value Delivered in Cloud Transformation]]（需求管理是价值交付的前置流程）
+- [[CTP Topic 4 Using Agile to Run the Cloud Transformation Programme]] ← relates_to ← [[CTP Topic 65 Tracing the Value Delivered in Cloud Transformation]]（敏捷方法支撑价值交付的迭代循环）
 
 ## Contradictions
-- 与 [[ctp-topic-53-why-bother-with-cloud]] 的视角张力：Topic 53 质疑迁移必要性，Topic 65 假设迁移已决策并聚焦如何量化交付价值。两者互补而非逻辑矛盾——前者回答"是否迁移"，后者回答"如何衡量价值"。
+- （暂无发现与其他 Wiki 页面的明显冲突）

wiki/sources/public-cloud-learning-sessions-opentext-evolving-from-dr-to-recovery-assurance-2.md

@@ -37,22 +37,26 @@ date: 2024-07-23
 - [[RTO]]（Recovery Time Objective）：事件发生后恢复服务所需时间，OpenText 跨度从分钟到数天
 - [[RPO]]（Recovery Point Objective）：可接受的最大数据丢失量，同样因客户合同而异
 - [[SRE]]（Site Reliability Engineering）：用软件工程思维解决运维问题，追求可靠性、可测试性、可重复性
-- [[Observability Engineering]]（可观测性工程）：通过遥测数据持续理解系统健康状态，是 Recovery Assurance 的技术基础
-- [[Disaster Recovery]]（灾难恢复）：保护系统免受灾难性事件影响的策略与实践
-- [[Business Continuity Plan]]（业务连续性计划）：确保业务在灾难期间持续运营的规划框架
+- [[Observability]]（可观测性）：通过遥测数据持续理解系统健康状态，是 Recovery Assurance 的技术基础
+- [[Disaster-Recovery]]（灾难恢复）：保护系统免受灾难性事件影响的策略与实践
 - [[Self-Healing]]（自愈能力）：软件应具备持续监控系统健康并在无需人工干预情况下自动恢复的能力
-- [[Customer Zero Environment]]：新版本发布前的内部验证环境，用于在真实流量前发现潜在问题
+- [[Customer-Zero]]（Customer Zero Environment）：新版本发布前的内部验证环境，用于在真实流量前发现潜在问题
+- [[Recovery-Assurance]]（恢复保证）：DR 的演进方向，从被动应对转向主动设计、持续验证、自动化保证系统恢复能力
 
 ## Key Entities
 - [[OpenText]]：企业信息管理公司，托管于 AWS/GCP/Azure 多云环境，由 Jim Rose 主讲本次学习会议
-- [[Jim Rose]]：OpenText 技术负责人/演讲者，分享 DR 向 Recovery Assurance 演进的实践与思考
 - [[CrowdStrike]]：2024 年引发全球大规模系统中断的安全软件公司，作为 DR 重要性案例被引用
 
 ## Connections
-- [[ctp-topic-72-enterprise-dr-strategy-aws-backup]] ← related_to ← [[public-cloud-learning-sessions-opentext-evolving-from-dr-to-recovery-assurance-2]]（均涉及企业 DR 策略，CTP Topic 72 提供 AWS Backup 层面的具体实现，本视频提供组织层面的演进思维）
+- [[ctp-topic-72-implementing-an-enterprise-dr-strategy-using-aws-backup]] ← related_to ← [[public-cloud-learning-sessions-opentext-evolving-from-dr-to-recovery-assurance-2]]（均涉及企业 DR 策略，CTP Topic 72 提供 AWS Backup 层面的具体实现，本视频提供组织层面的演进思维）
 - [[ctp-topic-41-nfrs-and-error-budgets]] ← related_to ← [[public-cloud-learning-sessions-opentext-evolving-from-dr-to-recovery-assurance-2]]（NFR/Error Budget 是 SRE 度量弹性目标的工具，与本视频的 SRE 转型方向一致）
 - [[ctp-topic-67-cloud-native-observability-using-opentelemetry]] ← related_to ← [[public-cloud-learning-sessions-opentext-evolving-from-dr-to-recovery-assurance-2]]（可观测性工程是 Recovery Assurance 的技术基础，OpenTelemetry 是具体实现路径）
 - [[ctp-topic-59-achieving-reliability-with-amazon-eks]] ← related_to ← [[public-cloud-learning-sessions-opentext-evolving-from-dr-to-recovery-assurance-2]]（EKS 可靠性工程实践与本视频的四位框架中的 Environments 层对应）
+- [[Disaster-Recovery]] ← described_by ← [[public-cloud-learning-sessions-opentext-evolving-from-dr-to-recovery-assurance-2]]（本视频是 DR 向 Recovery Assurance 演进的权威来源）
+- [[Recovery-Assurance]] ← introduced_by ← [[public-cloud-learning-sessions-opentext-evolving-from-dr-to-recovery-assurance-2]]（Recovery Assurance 四位框架在本视频中首次系统阐述）
+- [[Observability]] ← technology_enabler ← [[public-cloud-learning-sessions-opentext-evolving-from-dr-to-recovery-assurance-2]]（可观测性是 Recovery Assurance 的核心技术基础）
+- [[Self-Healing]] ← software_capability ← [[public-cloud-learning-sessions-opentext-evolving-from-dr-to-recovery-assurance-2]]（自愈能力是 Recovery Assurance 在软件层面的实现）
+- [[Customer-Zero]] ← validation_environment ← [[public-cloud-learning-sessions-opentext-evolving-from-dr-to-recovery-assurance-2]]（Customer Zero 是 Recovery Assurance Build 环节的核心实践）
 
 ## Contradictions
 - 无已知冲突。本视频提供 DR 向 Recovery Assurance 演进的方法论框架，与现有 Wiki 中的 DR 相关内容（CTP Topic 72 AWS Backup 实施、CTP Topic 44 AWS Backup 评估）互补而非冲突，共同构成完整的 DR 知识体系。

wiki/sources/public-cloud-learning-sessions-opentext-tagging-standard-v2-20250429-170111-meet.md

@@ -1,41 +1,60 @@
 ---
 title: "Public Cloud Learning Sessions - OpenText Tagging Standard v2 - 20250429"
 type: source
-tags: []
-date: 2026-04-14
+tags:
+  - OpenText
+  - Tagging-Standard
+  - FinOps
+  - Cloud-Governance
+  - Kubernetes
+  - Container
+date: 2026-04-29
 ---
 
 ## Source File
 - [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/public-cloud-learning-sessions-opentext-tagging-standard-v2-20250429-170111-meet.md]]
 
 ## Summary（用中文描述）
-- 核心主题：OpenText 云资源标签标准 v2——覆盖云账户、云资源、Kubernetes 对象和容器镜像的统一标签规范
-- 问题域：云成本优化、资源安全合规、服务交付自动化
-- 方法/机制：通过标准化标签前缀（OT\_ / app.opentext.com / com.opentext.image）实现跨云平台的统一标签语义；IaC 自动化标签创建与维护
-- 结论/价值：标签标准化是 FinOps 成本优化的基础，同时支撑安全合规、资源组织和自动化工作流
+- 核心主题：OpenText 云标签标准 V2 版本——扩展至 Kubernetes 对象和容器镜像标签规范
+- 问题域：云资源标签不一致、成本归属困难、Kubernetes 和容器镜像缺乏标签标准
+- 方法/机制：OT_ 前缀（云资源）、app.opentext.com 前缀（K8s 标签）、com.opentext.image 前缀（容器镜像）、Terraform IaC 自动打标
+- 结论/价值：V2 在 2023 年 V1 基础上扩展覆盖范围至 K8s 和容器镜像，帮助统一 3,500 个云账户的标签体系
 
 ## Key Claims（用中文描述）
-- OpenText 通过标准化标签驱动成本优化的三大机制：成本分配、风险降低（快速定位技术联系人）、自动化效率提升
-- Phenops 团队 2023 年发起的标签标准现已扩展至 Kubernetes 对象和容器镜像，覆盖 3,500 个云账户和 48 种 landing zone 类型
-- 标签治理最佳实践：IaC 自动化替代手动打标、检测报告发现缺失标签、禁止在标签中存储敏感数据
+- 标签标准三大驱动：省钱（FinOps 成本优化）、降险（快速定位技术联系人）、提效（自动化筛选）
+- OpenText 管理约 3,500 个云账户、48 种 Landing Zone 类型，亟需统一的标签标准
+- V2 标签标准由 Phenops 团队于 2023 年发起，现已扩展至 Kubernetes 对象和容器镜像
+- 标签标准涵盖范围：云账户、云资源（计算/存储/网络）、K8s 对象（Namespace/Pod/Deployment/Service/ConfigMap）、容器镜像
+- 标准鼓励在现有专有标签基础上逐步采用标准标签，最终替代专有标签
+- 最佳实践：使用 Terraform IaC 自动打标、创建检查和报告检测缺失标签、不在标签中存储敏感数据
 
 ## Key Quotes
-> "Tags are key-value pairs that typically have a tag key and an optionally a key value, which you can attach to cloud resources, cloud accounts, container images, Kubernetes objects and other things." — 标签的核心定义
-> "It is about taking resources and you will learn more in the presentation about what kinds of object and what exactly and so on." — 标签标准的适用对象概述
+> "It is about taking resources and you will learn more in the presentation about what kinds of object and what exactly and so on." — Martin Rosler 介绍 V2 标准覆盖的资源类型范围
+
+> "Texts are key value pairs that typically have a tag key and an optionally a key value, which you can attach to cloud resources, cloud accounts, container images, Kubernetes objects and other things." — 标签本质定义
 
 ## Key Concepts
-- [[Terraform]]：基础设施即代码工具，用于自动化标签创建和维护
-- [[Kubernetes]]：容器编排平台，标签标准扩展至其对象（namespaces、pods、deployments、services、config maps）
-- [[Container-Images]]：容器镜像，标签标准包含 product、title、description、vendor 等元数据标签
+- [[Resource-Tagging]]：云资源标签的核心概念，V2 扩展了 K8s 和容器镜像维度
+- [[FinOps]]：云财务管理，三大驱动之一
+- [[AWS-Tagging-Standards]]：OpenText 标签标准是 AWS 标签规范的扩展
+- [[Terraform]]：通过 IaC 自动化标签创建和维护
+- [[Kubernetes-Tagging]]（待新建）：K8s 标签标准，app.opentext.com 前缀
+- [[Container-Image-Tagging]]（待新建）：容器镜像标签标准，com.opentext.image 前缀
+- [[Multi-Cloud-Governance]]：跨云统一标签治理
 
 ## Key Entities
-- [[Martin-Rosler]]：讲师，介绍 OpenText Tagging Standard V2 的核心内容和三大驱动力
-- [[Phenops-Team]]：发起标签标准（2023年）的团队，原始版本已扩展 Kubernetes 和容器镜像指南
+- [[Phenops-Team]]：发起并维护 OpenText 标签标准的 FinOps 执行团队
+- [[OpenText]]：企业主体，管理 3,500 个云账户的标签治理
+- [[Martin Rosler]]（待新建）：V2 标签标准演讲者
 
 ## Connections
-- [[ctp-topic-28-aws-tag-validation-tool]] ← relates_to ← [[OpenText-Tagging-Standard-v2]]（两者均关注标签合规审计与强制执行）
-- [[ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security]] ← relates_to ← [[OpenText-Tagging-Standard-v2]]（标签即凭证的云原生安全架构理念一致）
-- [[ctp-topic-28-aws-tag-validation-tool]] ← extends ← [[ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security]]（审计工具是对 SCP 预防控制的存量检查补充）
+- [[public-cloud-learning-sessions-tagging-standards-for-all-hyperscalers-20240123]] ← extends ← 本页
+  - V2 是 V1 的扩展，V1 覆盖云账户/云资源，V2 新增 K8s 对象和容器镜像
+- [[ctp-topic-28-aws-tag-validation-tool]] ← relates_to ← 本页
+  - Tag Validation Tool 可用于验证 V2 标签标准的合规性
+- [[public-cloud-learning-sessions-reducing-cloud-costs-20250318]] ← relates_to ← 本页
+  - FinOps 成本优化是标签标准三大驱动之一，V2 补充了标准化标签体系
+- [[Resource-Tagging]] ← is_source_of ← 本页
 
 ## Contradictions
-- 与 [[ctp-topic-28-aws-tag-validation-tool]] 在标签强制能力边界上无矛盾，两者互补：标签标准定义「应该怎么标」，验证工具发现「谁没标好」
+- 无明显冲突。V2 在 V1 基础上扩展，保持向前兼容