Auto-sync: 2026-04-28 20:03

wiki/concepts/ADM.md

@@ -0,0 +1,28 @@
+---
+title: "ADM"
+type: concept
+tags: [AWS, Governance, Architecture]
+last_updated: 2026-05-07
+---
+
+## Definition
+
+ADM stands for **Architecture Decision Management** — the governance process for managing architecture decisions within an enterprise cloud environment. In the context of [[ctp-topic-50-ami-roadmap-for-aws-amis]], ADM is the primary driver for prioritizing the [[ARM-AMI]] roadmap.
+
+## Role in AMI Governance
+
+The [[CCOE]] AMI roadmap prioritization is primarily driven by ADM requirements. Any changes to roadmap prioritization must go through the demand pipeline process:
+
+> "The order was created mainly by ADM requirements. Any requirements to change the prioritization of the roadmap should go through the demand pipeline process." — [[ctp-topic-50-ami-roadmap-for-aws-amis]]
+
+## Related Concepts
+
+- [[Foundation-AMI]]: CCOE-provided hardened base images
+- [[OS-End-of-Life]]: OS lifecycle management that feeds into ADM decision-making
+- [[CCOE]]: Organization responsible for AMI governance and roadmap maintenance
+
+## Connections
+
+- [[ctp-topic-50-ami-roadmap-for-aws-amis]] → AMI roadmap is primarily driven by ADM requirements
+- [[ctp-topic-26-standard-ami-build-publish-share-processes]] → ADM decisions influence Foundation AMI feature set
+- [[ctp-topic-20-program-demand-process-flow-and-poc-onboarding]] → demand pipeline process for changing priorities

wiki/concepts/AMI-Sharing.md

@@ -0,0 +1,52 @@
+---
+title: "AMI Sharing"
+type: concept
+tags:
+  - AWS
+  - AMI
+  - Multi-Account
+sources: []
+last_updated: 2026-05-07
+---
+
+## AMI Sharing
+
+AWS 镜像跨账号共享机制，通过授权其他 AWS 账户访问中央镜像，而非物理复制（AMI Copying），避免跨账号复制带来的额外存储成本。
+
+## Definition
+
+AMI Sharing 是 AWS 账户管理策略，允许 AMI 所有者：
+- 将 AMI 共享给特定 AWS 账户
+- 将 AMI 共享给 AWS Organization 内所有成员账户
+- 通过 RAM（Resource Access Manager）前缀列表跨账户共享规则
+
+## Benefits vs AMI Copying
+
+| 维度 | AMI Sharing | AMI Copying |
+|------|-------------|-------------|
+| 存储成本 | 零增量 | 每区域完整副本 |
+| 一致性 | 单一源，完全一致 | 复制后可能不一致 |
+| 维护 | 单一更新点 | 每副本需独立更新 |
+| 权限 | 通过 IAM/KMS 控制 | 独立权限管理 |
+
+## In Micro Focus CTP
+
+在 Micro Focus 多账户 AWS 环境中：
+- Foundation AMI 存储在 CCOE 管理账户
+- 通过 AMI Sharing 分发给所有产品账户
+- 同步分发至全球多区域（俄勒冈/法兰克福/悉尼）
+- EBS 卷和 KMS 密钥同步共享
+
+## Prerequisites
+
+- AMI 所有者账户与目标账户在同一 AWS Organization，或
+- 显式授权跨账户共享
+- KMS 加密 AMI 需额外授权 KMS 密钥使用
+
+## Sources
+- [[ctp-topic-26-standard-ami-build-publish-share-processes]] — AMI Sharing 作为分发机制
+- [[ctp-topic-50-ami-roadmap-for-aws-amis]] — AMI 通过跨账号共享分发给组织内所有账户
+
+## Related Concepts
+- [[Foundation-AMI]] — AMI Sharing 分发的主要对象
+- [[AWS]] Organizations — 跨账号共享的组织基础

wiki/concepts/ARM-AMI.md

@@ -0,0 +1,40 @@
+---
+title: "ARM-AMI"
+type: concept
+tags: [AWS, AMI, ARM]
+last_updated: 2026-05-07
+---
+
+## Definition
+
+ARM-AMI refers to Amazon Machine Images (AMIs) built for EC2 instances running on ARM-based processors (Graviton/Graviton2/Graviton3). These AMIs are optimized for ARM architecture and offer better price-performance ratio compared to x86 AMIs for many workloads.
+
+## Key Characteristics
+
+- **Architecture**: ARM64 (AArch64), based on AWS Graviton processor family
+- **Performance**: Better price-performance for many workloads (web servers, containers, microservices)
+- **Cost**: Lower licensing costs (no x86 licensing fees)
+- **Availability**: Available for Amazon Linux, Ubuntu, RHEL, and other supported OSes
+- **Shared Infrastructure**: AMIs, EBS volumes, and KMS keys shared across all organization accounts
+
+## AMI Roadmap Context
+
+Per [[ctp-topic-50-ami-roadmap-for-aws-amis]], the ARM-AMI roadmap milestones:
+
+- **November 2022**: RHEL 9 ARM planned
+- **May 2023**: RHEL 9.4 ARM and Ubuntu 22.04 ARM
+- **Starting May 2023**: All ARM processors related to AMIs are released synchronously
+
+The ordering of ARM AMI releases is primarily driven by [[ADM]] (Architecture Decision Management) requirements.
+
+## Related Concepts
+
+- [[Foundation-AMI]]: CCOE-provided hardened base images on which product teams build
+- [[AMI-Sharing]]: Cross-account AMI sharing mechanism
+- [[OS-Hardening]]: Security hardening applied to AMIs
+
+## Connections
+
+- [[ctp-topic-50-ami-roadmap-for-aws-amis]] → defines ARM-AMI release roadmap
+- [[ctp-topic-26-standard-ami-build-publish-share-processes]] → foundation AMI hardening standards apply to ARM variants
+- [[ctp-topic-58-aws-ec2-image-builder]] → Image Builder used to create ARM-variant AMIs

wiki/concepts/AWS-Backup-Concepts.md

@@ -0,0 +1,61 @@
+---
+title: "AWS Backup Concepts"
+type: concept
+tags:
+  - AWS
+  - Backup
+  - DR
+  - Cloud-Native
+sources:
+  - ctp-topic-72-implementing-an-enterprise-dr-strategy-using-aws-backup
+  - ctp-topic-73-aws-backup-implementation-of-the-cloud-transformation-program
+last_updated: 2026-04-28
+---
+
+# AWS Backup Concepts
+
+本页面汇总 AWS Backup 相关的核心概念。
+
+## Vault Lock（备份保管库锁定）
+
+Vault Lock 是 AWS Backup 备份保管库的一种合规模式。在合规模式下：
+
+- 一旦 Vault Lock 生效，即使 AWS 根用户也无法在设定的生命周期结束前删除恢复点
+- 有效防御勒索软件攻击（攻击者无法加密/删除备份）
+- 适用于需要满足监管合规要求（如 SEC、FINRA、GDPR）的场景
+
+> 对比 CTP Topic 44（Micro Focus 评估）：Micro Focus 内部评估同样认可 Vault Lock 是防勒索软件的关键能力。
+
+## 增量备份（Incremental Backup）
+
+增量备份仅捕获自上次备份以来的数据变更：
+
+- **优势**：首次全量备份后，后续仅备份变更，大幅节省存储成本
+- **机制**：备份链（Backup Chain）追踪变更，恢复时按顺序重放
+- **AWS Backup 自动处理**：无需手动管理备份链
+
+> 与全量备份相比，增量备份显著降低了存储成本和备份窗口时长。
+
+## 跨账户备份（Cross-Account Backup）
+
+通过 AWS Organizations 将备份从源账户复制到独立的 DR/Bunker 账户：
+
+- **隔离原则**：备份账户与工作负载账户物理分离，防止账户被入侵时备份一并丢失
+- **即时恢复**：备份保留在 DR 账户内，无需跨账户数据拷贝即可恢复
+- **多区域复制**：结合跨区域复制，实现地理冗余
+
+## Backup Plan（备份计划）
+
+备份计划是 AWS Backup 的核心策略配置：
+
+- **规则（Rules）**：定义备份频率、保留期、启动窗口、复制规则等
+- **分配（Assignments）**：将计划应用于特定资源或资源集
+- **生命周期（Lifecycle）**：定义恢复点何时从热存储转为冷存储（Glacier）
+
+## Backup Vault（备份保管库）
+
+备份保管库是存储恢复点的加密容器：
+
+- 每个保管库使用 AWS KMS CMK 加密
+- 支持基于资源的策略（Resource-based Policy）控制访问
+- 与 Vault Lock 结合实现合规锁定

wiki/concepts/AWS-Inspector.md

@@ -0,0 +1,27 @@
+---
+title: "AWS Inspector"
+type: concept
+tags: ["AWS", "Security", "Vulnerability-Scanning", "Compliance"]
+sources: ["learning-sessions-standard-amis-updates-20231205-160324-meeting-recording-2", "ctp-topic-58-aws-ec2-image-builder"]
+last_updated: 2026-05-08
+---
+
+## Definition
+AWS Inspector 是 AWS 原生的安全漏洞扫描服务，在 AMI 构建和发布流程中集成自动化的安全合规检测，识别已知安全漏洞（CVE）和网络暴露问题。
+
+## Key Capabilities
+- **CVE 检测**：识别已知安全漏洞
+- **网络可达性分析**：检测意外开放的安全组规则
+- **自动扫描**：集成到 CI/CD 流水线
+- **合规报告**：生成安全扫描报告
+
+## Integration in AMI Pipeline
+1. AMI 构建完成后立即触发 Inspector 扫描
+2. 扫描结果与安全基准对比
+3. 发现高危漏洞则阻断发布
+4. 无问题则继续跨区域复制和共享
+
+## Connections
+- [[Amazon-Machine-Image]] — Inspector 扫描的对象
+- [[Jenkins-Multi-Branch-Pipeline]] — Inspector 集成在 Jenkins 流水线中
+- [[AWS-Landing-Zone]] — Inspector 是 LZ 安全基础设施的组成部分

wiki/concepts/Active-Directory-Integration.md

@@ -0,0 +1,42 @@
+---
+title: "Active-Directory-Integration"
+type: concept
+tags: [Identity, AWS, Networking]
+sources: [ctp-topic-7-saas-landing-zone-design]
+last_updated: 2026-05-06
+---
+
+## Active-Directory-Integration
+
+AWS 环境中的 Active Directory 集成方案，用于实现统一的身份认证和资源访问控制。
+
+## Definition
+
+Active Directory 集成是 Landing Zone 基线服务的重要组成部分：
+- **核心功能**：通过双 AD 节点实现域加入（Domain Join）和资源访问控制
+- **部署位置**：独立的 Active Directory Account（基线账户层）
+- **认证用途**：用于 AWS Workspaces、EC2 实例（Windows/Linux）、VPN 接入等场景的身份认证
+
+## Role in SAS Landing Zone
+
+在 [[ctp-topic-7-saas-landing-zone-design]] 定义的 Baseline 账户中：
+- **部署**：Active Directory 账户托管两个 AD 节点（双节点高可用）
+- **用途 1**：域加入（Domain Join）— Windows 和 Linux 实例自动加入 AD 域
+- **用途 2**：资源访问控制 — 基于 AD 组映射 IAM 角色，实现最小权限原则
+- **用途 3**：VPN 认证 — Pulse VPN 通过 AD 认证远程访问人员身份
+
+## Key Properties
+- **Type**: Identity & Access Management
+- **Architecture**: 双 AD 节点高可用
+- **In SAS LZ Layer**: Baseline Accounts
+
+## Related Concepts
+- [[Domain-Join]] — 实例域加入机制
+- [[Federated-Access]] — 联邦身份认证
+- [[Multi-factor-Authentication]] — 多因素认证
+
+## Connections
+- [[ctp-topic-7-saas-landing-zone-design]] — SAS LZ 基线账户身份认证基础设施
+- [[ctp-topic-11-ad-integration-and-login-using-ad-accounts]] — AD 集成与登录详细实践
+- [[ctp-topic-17-active-directory-services-in-gruntwork-aws-lzs]] — Gruntwork LZ 中的 AD 服务集成
+- [[ctp-topic-6-aws-workspaces-demo]] — AWS Workspaces 使用 AD 账号登录

wiki/concepts/Amazon-Machine-Image.md

@@ -0,0 +1,42 @@
+---
+title: "Amazon Machine Image"
+type: concept
+tags: ["AWS", "Virtualization", "AMI", "Landing-Zone"]
+sources: ["learning-sessions-standard-amis-updates-20231205-160324-meeting-recording-2", "ctp-topic-50-ami-roadmap-for-aws-amis", "ctp-topic-26-standard-ami-build-publish-share-processes"]
+last_updated: 2026-05-08
+---
+
+## Definition
+Amazon Machine Image (AMI) 是 AWS 托管的虚拟机镜像模板，包含操作系统、应用程序和配置。在 Micro Focus AWS Landing Zone 中，标准 AMI 在 AWS 原生镜像基础上增加了企业级组件。
+
+## Standard AMI Components
+标准 AMI 在 AWS 原生镜像基础上增加：
+- **OS 加固**：CIS 安全基准加固
+- **安全更新**：最新补丁和安全更新
+- **域名加入**：支持 AD 域集成
+- **安全工具**：McAfee EPO / Trellix / Sentinel-1 端点保护
+- **QALIS Agent**：企业端点保护
+- **SSM Agent**：AWS Systems Manager Agent
+- **DNS 设置**：企业 DNS 配置
+- **GP3 EBS 存储**：第三代通用型 SSD
+
+## AMI Release Process
+1. **功能分支开发**：变更在功能分支上开发
+2. **集成分支合并**：合并到集成分支
+3. **Jenkins 构建**：Jenkins 多分支流水线构建和测试
+4. **安全扫描**：AWS Inspector 漏洞检测
+5. **跨区域复制**：AMI Copying 复制到不同区域
+6. **跨账号共享**：AMI Sharing 分发到多个组织和账户
+7. **加密共享**：自动创建必要的授权（grants）
+8. **完整测试套件**：验证无功能退化
+
+## AMI Types in AWS Landing Zone
+- **Foundation AMI**（标准 AMI）：CCOE 提供的基线镜像
+- **Product AMI**：产品团队在 Foundation AMI 基础上定制
+
+## Connections
+- [[AWS-Landing-Zone]] — AMI 是 LZ 标准化的核心基础设施
+- [[Jenkins-Multi-Branch-Pipeline]] — 驱动 AMI 构建和测试
+- [[AWS-Inspector]] — AMI 安全扫描集成
+- [[SSM-Patching]] — 长期运行实例的补丁管理
+- [[OS-End-of-Life]] — AMI EOL 管理

wiki/concepts/DNS-Anycast.md

@@ -0,0 +1,47 @@
+---
+title: "DNS Anycast"
+type: concept
+tags: [DNS, Networking, High-Availability, Infoblox]
+sources: []
+last_updated: 2026-05-07
+---
+
+## DNS Anycast
+
+一种网络寻址和路由方法，使多个地理位置分布的 DNS 服务器共享同一个 IP 地址，将用户请求路由至地理位置最近的节点，从而实现极低的延迟和自动故障转移。
+
+## How It Works
+
+传统 DNS 使用 Unicast（单播），每个服务器节点有独立 IP 地址。Anycast 则让多个节点使用相同的 IP：
+
+1. **路由层**：BGP 协议根据网络拓扑将请求路由到最近的节点
+2. **低延迟**：用户请求自动被引导至物理距离最近的服务器
+3. **高可用**：当某个节点不可用时，路由协议自动将流量切换到次近节点
+
+## Enterprise Use Case: Infoblox
+
+企业级 DNS 平台（如 Infoblox）广泛使用 Anycast：
+
+- **Grid 架构**：全球分布的 Infoblox 设备共享同一 VIP（Virtual IP）
+- **自动故障转移**：单点故障不影响服务
+- **DDoS 缓解**：分布式架构吸收恶意流量
+
+## AWS Limitation
+
+AWS EC2 基础架构目前不支持 Anycast：
+
+- EC2 实例无法共享同一弹性 IP 进行 Anycast 路由
+- 需要手动维护多 IP 地址列表实现高可用冗余
+- 这是选择 Route 53（托管服务）vs 自建 EC2 DNS 的重要考量
+
+## Key Concepts
+
+- [[Infoblox Grid]]：企业级 DNS/DHCP/IPAM 平台的分布式架构
+- [[Route 53]]：AWS 托管 DNS 服务（使用 Anycast 自身运营，但不支持客户自建）
+- [[Hybrid DNS Resolution]]：混合云 DNS 解析架构
+
+## Aliases
+
+- DNS Anycast
+- Anycast DNS
+- IP Anycast

wiki/concepts/Distribution-Key.md

@@ -0,0 +1,51 @@
+---
+title: "Distribution Key"
+type: concept
+tags:
+  - Data-Engineering
+  - Database
+  - AWS-Redshift
+  - Performance-Optimization
+last_updated: 2026-04-14
+---
+
+## Definition
+
+Distribution Key（分布键，Dist Key）决定数据在分布式数据仓库集群各计算节点间的分布方式。合理的分布键选择是避免数据倾斜（Data Skew）和最小化跨节点数据传输（Data Shuffling）的关键。
+
+## Distribution Strategies
+
+### 1. KEY Distribution（关键分布）
+- 按特定列的哈希值分布数据
+- 同一键值的数据会落在同一节点
+- 适用场景：事实表与维度表基于外键的关联（Colocation Join）
+
+### 2. ALL Distribution（全分布）
+- 将小表完整复制到所有节点
+- 消除跨节点传输，但增加存储成本
+- 适用场景：小维度表（< 10MB）
+
+### 3. EVEN Distribution（均匀分布）
+- 轮询方式均匀分布数据
+- 默认策略，适用于无明显热点的情况
+- 适用场景：无法确定最佳分布键时的兜底策略
+
+## Key Trade-offs
+
+| 维度 | KEY | ALL | EVEN |
+|------|-----|-----|------|
+| 存储成本 | 低 | 高 | 低 |
+| Join 性能 | 高（co-located） | 高 | 低（可能 shuffle） |
+| 数据倾斜风险 | 中（取决于键值分布） | 无 | 无 |
+| 适用表规模 | 大表 | 小表 | 通用 |
+
+## Related Concepts
+
+- [[Sort-Key]]：节点内数据排序，与 Distribution Key 共同构成 Redshift 性能优化双核心
+- [[Data-Skew]]：分布键选择不当导致的数据倾斜问题
+- [[MPP]]：分布键决定数据局部性，影响 MPP 并行效率
+- [[Amazon-Redshift]]：Distribution Key 是 Redshift 架构的核心概念
+
+## Sources
+
+- [[ctp-topic-68-introduction-to-redshift]]：Distribution Key 在 Redshift 集群数据分布中的作用

wiki/concepts/Foundation-AMI.md

@@ -0,0 +1,55 @@
+---
+title: "Foundation AMI"
+type: concept
+tags:
+  - AWS
+  - AMI
+  - Security
+  - Cloud
+sources: []
+last_updated: 2026-05-07
+---
+
+## Foundation AMI
+
+经过安全加固、集成标准组件并预配置好的操作系统模板，是 Micro Focus 云环境的标准化基础镜像。
+
+## Definition
+
+Foundation AMI 是基于市场主流操作系统（如 CentOS, Ubuntu, Windows 等）进行深度加固的镜像，集成了：
+
+- [[CIS-Benchmark]] 安全基准：遵循互联网安全中心制定的安全配置基准
+- **McAfee EPO**：企业级防病毒软件
+- **Syslog-ng**：日志管理
+- **AD 单点登录**：Active Directory 集成认证
+- [[AWS-SSM]]：AWS 系统管理器代理，用于远程管理、自动化补丁更新和配置同步
+- **SiteScope**：监控预选件
+
+## Build Automation
+
+通过 [[HashiCorp]] Packer + [[Jenkins]] 流水线实现镜像创建完全自动化：
+- Packer 负责从单一源配置自动创建一致的机器镜像
+- Jenkins 流水线管理构建、测试和发布流程
+
+## Distribution
+
+通过跨账号共享（AMI Sharing）分发至全球多区域（俄勒冈/法兰克福/悉尼等），而非物理复制（AMI Copying），避免额外存储成本。
+
+## Update Policy
+
+- 更新频率：每两个月更新一次
+- 版本保留策略：N-2（保留当前及前两个版本）
+- 通知机制：通过 CCOE 门户订阅 AMI 更新通知
+
+## Relationship with Product-Specific AMI
+
+Foundation AMI 是基础层，产品团队在其之上构建"产品特定 AMI"（Product-Specific AMI），以满足各自应用的特殊需求，并负责其后续的生命周期管理。
+
+## Aliases
+- CCOE AMI
+- Golden AMI
+- Base AMI
+
+## Sources
+- [[ctp-topic-26-standard-ami-build-publish-share-processes]] — Foundation AMI 全生命周期管理详解
+- [[ctp-topic-50-ami-roadmap-for-aws-amis]] — AMI 路线图中 Foundation AMI 的定义

wiki/concepts/GP3-EBS-Storage.md

@@ -0,0 +1,28 @@
+---
+title: "GP3 EBS Storage"
+type: concept
+tags: ["AWS", "Storage", "EBS", "Block-Storage"]
+sources: ["learning-sessions-standard-amis-updates-20231205-160324-meeting-recording-2"]
+last_updated: 2026-05-08
+---
+
+## Definition
+GP3 EBS Storage（第三代通用型 SSD）是 AWS EBS 的存储类型，Micro Focus AWS Landing Zone 标准 AMI 默认采用。GP3 提供一致的 3,000 IOPS 基础性能和 125 MiB/s 吞吐量，可独立扩展存储性能和成本。
+
+## Key Characteristics
+- **性能**：可独立配置 IOPS（最高 16,000）和吞吐量
+- **成本**：比 GP2 降低约 20% 成本
+- **基准性能**：3,000 IOPS + 125 MiB/s（包含在价格中）
+- **最大性能**：16,000 IOPS + 1,000 MiB/s
+
+## GP2 vs GP3 Comparison
+| 特性 | GP2 | GP3 |
+|------|-----|-----|
+| 容量范围 | 1 GiB - 16 TiB | 1 GiB - 16 TiB |
+| IOPS | 3,000 - 16,000 | 3,000 - 16,000（独立配置） |
+| 吞吐量 | 与容量耦合 | 125 - 1,000 MiB/s（独立配置） |
+| 成本 | 较高 | 较低 |
+
+## Connections
+- [[Amazon-Machine-Image]] — GP3 是标准 AMI 的默认存储配置
+- [[AWS-Landing-Zone]] — 标准化的 GP3 配置是 LZ 存储策略的一部分

wiki/concepts/Jenkins-Multi-Branch-Pipeline.md

@@ -0,0 +1,36 @@
+---
+title: "Jenkins Multi-Branch Pipeline"
+type: concept
+tags: ["CI/CD", "Jenkins", "Automation", "DevOps"]
+sources: ["learning-sessions-standard-amis-updates-20231205-160324-meeting-recording-2"]
+last_updated: 2026-05-08
+---
+
+## Definition
+Jenkins 多分支流水线（Jenkins Multi-Branch Pipeline）是 Jenkins 的流水线即代码功能，支持根据 Git 分支自动创建和管理流水线。在 Micro Focus AWS Landing Zone 中，用于 AMI 构建和 IaC 部署的双重场景。
+
+## Architecture Pattern
+- **Feature Branch Pipeline**：功能分支上变更 → 开发测试 → 合并到集成分支
+- **Integration Branch Pipeline**：集成分支合并 → 构建 → 测试 → 发布
+- **Jenkinsfile**：在代码仓库中定义流水线即代码
+
+## Dual Use Cases
+
+### AMI 构建
+1. Jenkins 扫描 Git 仓库的分支
+2. 每个分支触发独立流水线
+3. HashiCorp Packer 执行镜像构建
+4. 脚本化测试 + AWS Inspector 安全扫描
+5. 跨区域 AMI 复制和共享
+
+### IaC 部署（Terraform/TerraGrunt）
+1. GitHub 仓库变更触发 Jenkins
+2. Terraform Plan 输出变更计划
+3. 审批后执行 Terraform Apply
+4. 跨账户角色切换部署
+
+## Connections
+- [[Jenkins]] — 托管多分支流水线的 CI/CD 平台
+- [[Terraform-IaC]] — 流水线编排的 IaC 工具
+- [[Terragrunt]] — 配合 Terraform 的 DRY 工具
+- [[Amazon-Machine-Image]] — 多分支流水线构建的产物

wiki/concepts/OS-End-of-Life.md

@@ -0,0 +1,33 @@
+---
+title: "OS End of Life"
+type: concept
+tags: ["Linux", "Windows", "Lifecycle-Management", "Migration"]
+sources: ["learning-sessions-standard-amis-updates-20231205-160324-meeting-recording-2", "ctp-topic-50-ami-roadmap-for-aws-amis"]
+last_updated: 2026-05-08
+---
+
+## Definition
+操作系统生命周期终止（OS End of Life，EOL）是指操作系统供应商停止支持、安全更新和补丁的日期。在 Micro Focus AWS Landing Zone 中，EOL 管理是 AMI 策略的重要组成部分，需要提前规划迁移到受支持的替代操作系统。
+
+## Key EOL Dates in AWS Landing Zone
+
+### 已 EOL
+- **Windows Server 2008 / 2008 R2**：已 EOL
+- **CentOS 8**：已 EOL（2021 年 12 月）
+
+### 即将 EOL（截至 2023-12 会议记录）
+- **CentOS 7**：2024 年 6 月 EOL → 替代方案：Rocky Linux 8/9
+- **Red Hat Enterprise Linux 7**：2024 年 6 月 EOL → 替代方案：RHEL 9
+- **OpenSUSE Leap 15**：2024 年 12 月 EOL
+- **Oracle Enterprise Linux 7 (OEL 7)**：2024 年 12 月 EOL
+
+### AWS Landing Zone 应对策略
+1. **提前规划**：在 EOL 前 6 个月启动迁移评估
+2. **替代 AMI**：CCOE 发布新 OS 替代 AMI（如 Rocky Linux）
+3. **自动化迁移**：Terraform 模块支持 OS 层变更
+4. **验证测试**：在非生产环境验证兼容性
+
+## Connections
+- [[Rocky-Linux]] — CentOS 7 的官方替代品
+- [[Amazon-Machine-Image]] — EOL 管理通过 AMI 生命周期体现
+- [[ctp-topic-50-ami-roadmap-for-aws-amis]] — AMI 路线图包含 EOL 时间线规划

wiki/concepts/OS-Hardening.md

@@ -0,0 +1,59 @@
+---
+title: "OS Hardening"
+type: concept
+tags:
+  - Security
+  - Linux
+  - AWS
+sources: []
+last_updated: 2026-05-07
+---
+
+## OS Hardening
+
+操作系统加固，通过关闭不必要服务、优化内核参数和应用安全补丁来减少系统攻击面。
+
+## Definition
+
+OS Hardening 是将操作系统配置为最小权限、最小攻击面的过程，是 Foundation AMI 安全加固的核心步骤。
+
+## Key Areas
+
+### 1. Service Reduction
+- 禁用不必要的系统服务
+- 关闭未使用的网络端口
+- 移除不必要的软件包
+
+### 2. Kernel Parameters
+- 网络安全参数优化
+- 文件系统权限加固
+- 用户权限限制（最小权限原则）
+
+### 3. Security Patching
+- 操作系统安全补丁自动更新
+- 内核更新管理
+- 应用层安全补丁
+
+### 4. Compliance Alignment
+- 遵循 [[CIS-Benchmark]] 配置
+- 满足企业安全策略
+- 对接合规审计框架
+
+## In Foundation AMI
+
+Foundation AMI 的 OS Hardening 包括：
+- 基于 [[CIS-Benchmark]] 的安全配置
+- McAfee EPO 防病毒集成
+- Syslog-ng 日志管理
+- AD 单点登录集成
+- [[AWS-SSM]] 自动化补丁管理
+
+## Relationship with CIS Benchmark
+
+OS Hardening 通常基于 [[CIS-Benchmark]]：
+- [[CIS-Benchmark]] 提供配置检查清单
+- OS Hardening 是实际执行这些配置的过程
+- Foundation AMI 集成了经过 CIS 加固的操作系统
+
+## Sources
+- [[ctp-topic-26-standard-ami-build-publish-share-processes]] — Foundation AMI 中的 OS Hardening 实现

wiki/concepts/Private-Subnet-Architecture.md

@@ -0,0 +1,41 @@
+---
+title: "Private-Subnet-Architecture"
+type: concept
+tags: [AWS, Networking, Security]
+sources: [ctp-topic-7-saas-landing-zone-design]
+last_updated: 2026-05-06
+---
+
+## Private-Subnet-Architecture
+
+AWS VPC 私有子网架构原则 — 工作负载必须部署于私有子网，通过负载均衡器对外暴露服务的架构模式。
+
+## Definition
+
+私有子网架构是产品账户网络设计的核心原则：
+- **工作负载位置**：所有应用和服务（ECS、RDS、Lambda 等）部署于私有子网
+- **公网暴露**：仅通过公有子网的 Load Balancer（ALB/NLB）和 Internet Gateway 对外暴露
+- **安全优势**：减少公网攻击面，工作负载无需直接暴露公网 IP
+
+## Role in SAS Landing Zone
+
+在 [[ctp-topic-7-saas-landing-zone-design]] 定义的 Product Account 中：
+- **工作负载**：业务应用（Product workloads）必须部署于私有子网
+- **入站链路**：用户 → Internet Gateway → Load Balancer（公有子网）→ **工作负载（私有子网）**
+- **出站链路**：私有子网通过 NAT Gateway 或 VPC Endpoints 访问互联网或 AWS 服务
+
+## Key Properties
+- **Type**: Network Architecture Pattern
+- **Workload placement**: Private subnets (no direct internet exposure)
+- **External exposure**: Via Load Balancers only
+- **In SAS LZ**: Product Account 网络设计原则
+
+## Related Concepts
+- [[VPC-Endpoint]] — 私有访问 AWS 服务（无需 NAT）
+- [[Network-Segmentation]] — 网络分段策略
+- [[Defense-in-Depth]] — 纵深防御安全模型
+
+## Connections
+- [[ctp-topic-7-saas-landing-zone-design]] — SAS LZ 产品账户网络设计原则
+- [[ctp-topic-35-aws-landing-zone-design-refresher-saas-labs]] — 网络分段阻断 SaaS 直接连通性
+- [[ctp-topic-39-implementing-eks-in-the-aws-lab-landing-zone]] — EKS 在私有子网的部署实践

wiki/concepts/RPO.md

@@ -1,91 +1,91 @@
----
-title: "RPO (Recovery Point Objective)"
-tags: [devops, disaster-recovery, sre, reliability, data-protection]
-created: 2026-04-25
----
-
-# RPO (Recovery Point Objective)
-
-**RPO (Recovery Point Objective)** 是指系统发生故障时，能够接受的最大数据丢失量。它衡量的是数据保护程度——从故障时刻向前追溯，可接受丢失多长时间的数据。
-
-## Definition
-
-> "RPO is about protecting data. It's measured backwards from the moment of failure." — LaunchDarkly
-
-RPO 是灾备规划的核心指标之一，与 [[RTO]]（恢复时间目标）共同构成灾备目标体系。
-
-## Key Characteristics
-
-| 维度 | 说明 |
-|------|------|
-| **衡量对象** | 数据丢失量（Data Loss Amount） |
-| **测量方向** | 从故障时刻向后（Backwards）追溯 |
-| **关注点** | 数据完整性（How Much Data Can Be Lost） |
-
-## Example
-
-如果数据库在下午 3 点崩溃，而最后一次备份是下午 2 点，则：
-- **RPO = 1 小时**：这意味着过去 1 小时内的数据可能丢失
-- 2:00 到 3:00 之间发生的所有事务都面临丢失风险
-
-## RTO vs. RPO
-
-RTO 和 RPO 衡量的是不同维度，必须**同时优化**：
-
-| 场景 | RTO 目标 | RPO 目标 | 说明 |
-|------|----------|----------|------|
-| 电商结账 | 2 分钟 | 0 秒 | 必须快速恢复，且不能丢失任何交易 |
-| 用户分析面板 | 30 分钟 | 1 小时 | 停机可接受，小时级数据丢失也可接受 |
-| 内部 CRM | 4 小时 | 15 分钟 | 停机可绕过，但近期客户更新很重要 |
-| 博客/营销站 | 2 小时 | 24 小时 | 访问者可以等，丢失一天评论可接受 |
-
-**关键**：不能只优化其中一个指标。
-- 30 秒一次备份（RPO 优秀）但恢复需要 6 小时（RTO 极差）= 无效
-- 5 分钟拉起新服务器（RTO 优秀）但丢失 4 小时客户数据（RPO 极差）= 无效
-
-## [[Feature Flag]] 对 RPO 的保护
-
-传统回滚（Full Deployment Rollback）在回滚过程中可能丢失新事务数据。而 [[Feature Flag]] 回滚**不丢失数据**：
-
-- Feature Flag 切换只改变代码执行路径，不触碰数据层
-- [[Kill Switch]] 关闭故障功能时，用户正在提交的数据不受影响
-- RPO 在整个 Feature Flag 操作期间始终保持近零
-
-## Tiered RPO Targets
-
-| Tier | 场景 | RPO 目标 | 说明 |
-|------|------|----------|------|
-| Critical | 支付处理、交易系统 | < 1 分钟 | 不能丢失任何金钱相关数据 |
-| Important | CRM、客户支持 | < 15 分钟 | 近期客户更新不可丢失 |
-| Nice-to-have | 文档站、内部工具 | < 1 小时 | 数据可重建或接受丢失 |
-
-## 实现手段
-
-| 方法 | RPO 效果 | 说明 |
-|------|----------|------|
-| 无备份 | ∞ | 完全不可接受 |
-| 每日备份 | 24 小时 | 成本低，RPO 差 |
-| 每小时备份 | 1 小时 | 中等成本和效果 |
-| CDB（持续数据保护） | 秒级 | 持续复制，RPO 接近零 |
-| 同步复制（Active-Active） | 0 | 零数据丢失，成本极高 |
-
-## RPO 与 RTO 必须协同
-
-最佳实践是同时设定 RTO 和 RPO，并将 [[Feature Flag]] / [[Kill Switch]] 纳入灾备工具链：
-
-- RTO 短 → 系统快速恢复
-- RPO 小 → 数据损失少
-- Feature Flag → 两者兼得的性价比方案
-
-## Related Concepts
-
-- [[RTO]] — Recovery Time Objective，停机时间指标
-- [[Disaster Recovery]] — 灾备策略，RTO/RPO 是其核心目标
-- [[Feature Flag]] — 保护 RPO 的配置级热修复机制
-- [[Kill Switch]] — 关闭故障功能，保护数据不被继续破坏
-- [[High Availability]] — 高可用性，降低 RPO 的基础设施
-- [[Data-Governance]] — 数据治理，包含 RPO 策略
-
-## Sources
-
-- [[sources/rto-vs-rpo-key-differences-for-modern-disaster-recovery.md]]
+---
+title: "RPO (Recovery Point Objective)"
+tags: [devops, disaster-recovery, sre, reliability, data-protection]
+last_updated: 2026-04-28
+---
+
+# RPO (Recovery Point Objective)
+
+**RPO (Recovery Point Objective)** 是指系统发生故障时，能够接受的最大数据丢失量。它衡量的是数据保护程度——从故障时刻向前追溯，可接受丢失多长时间的数据。
+
+## Definition
+
+> "RPO is about protecting data. It's measured backwards from the moment of failure." — LaunchDarkly
+
+RPO 是灾备规划的核心指标之一，与 [[RTO]]（恢复时间目标）共同构成灾备目标体系。
+
+## Key Characteristics
+
+| 维度 | 说明 |
+|------|------|
+| **衡量对象** | 数据丢失量（Data Loss Amount） |
+| **测量方向** | 从故障时刻向后（Backwards）追溯 |
+| **关注点** | 数据完整性（How Much Data Can Be Lost） |
+
+## Example
+
+如果数据库在下午 3 点崩溃，而最后一次备份是下午 2 点，则：
+- **RPO = 1 小时**：这意味着过去 1 小时内的数据可能丢失
+- 2:00 到 3:00 之间发生的所有事务都面临丢失风险
+
+## RTO vs. RPO
+
+RTO 和 RPO 衡量的是不同维度，必须**同时优化**：
+
+| 场景 | RTO 目标 | RPO 目标 | 说明 |
+|------|----------|----------|------|
+| 电商结账 | 2 分钟 | 0 秒 | 必须快速恢复，且不能丢失任何交易 |
+| 用户分析面板 | 30 分钟 | 1 小时 | 停机可接受，小时级数据丢失也可接受 |
+| 内部 CRM | 4 小时 | 15 分钟 | 停机可绕过，但近期客户更新很重要 |
+| 博客/营销站 | 2 小时 | 24 小时 | 访问者可以等，丢失一天评论可接受 |
+
+**关键**：不能只优化其中一个指标。
+- 30 秒一次备份（RPO 优秀）但恢复需要 6 小时（RTO 极差）= 无效
+- 5 分钟拉起新服务器（RTO 优秀）但丢失 4 小时客户数据（RPO 极差）= 无效
+
+## [[Feature Flag]] 对 RPO 的保护
+
+传统回滚（Full Deployment Rollback）在回滚过程中可能丢失新事务数据。而 [[Feature Flag]] 回滚**不丢失数据**：
+
+- Feature Flag 切换只改变代码执行路径，不触碰数据层
+- [[Kill Switch]] 关闭故障功能时，用户正在提交的数据不受影响
+- RPO 在整个 Feature Flag 操作期间始终保持近零
+
+## Tiered RPO Targets
+
+| Tier | 场景 | RPO 目标 | 说明 |
+|------|------|----------|------|
+| Critical | 支付处理、交易系统 | < 1 分钟 | 不能丢失任何金钱相关数据 |
+| Important | CRM、客户支持 | < 15 分钟 | 近期客户更新不可丢失 |
+| Nice-to-have | 文档站、内部工具 | < 1 小时 | 数据可重建或接受丢失 |
+
+## 实现手段
+
+| 方法 | RPO 效果 | 说明 |
+|------|----------|------|
+| 无备份 | ∞ | 完全不可接受 |
+| 每日备份 | 24 小时 | 成本低，RPO 差 |
+| 每小时备份 | 1 小时 | 中等成本和效果 |
+| CDB（持续数据保护） | 秒级 | 持续复制，RPO 接近零 |
+| 同步复制（Active-Active） | 0 | 零数据丢失，成本极高 |
+
+## RPO 与 RTO 必须协同
+
+最佳实践是同时设定 RTO 和 RPO，并将 [[Feature Flag]] / [[Kill Switch]] 纳入灾备工具链：
+
+- RTO 短 → 系统快速恢复
+- RPO 小 → 数据损失少
+- Feature Flag → 两者兼得的性价比方案
+
+## Related Concepts
+
+- [[RTO]] — Recovery Time Objective，停机时间指标
+- [[Disaster Recovery]] — 灾备策略，RTO/RPO 是其核心目标
+- [[Feature Flag]] — 保护 RPO 的配置级热修复机制
+- [[Kill Switch]] — 关闭故障功能，保护数据不被继续破坏
+- [[High Availability]] — 高可用性，降低 RPO 的基础设施
+- [[Data-Governance]] — 数据治理，包含 RPO 策略
+
+## Sources
+- [[sources/rto-vs-rpo-key-differences-for-modern-disaster-recovery.md]]
+- [[sources/ctp-topic-72-implementing-an-enterprise-dr-strategy-using-aws-backup.md]]

wiki/concepts/RTO.md

@@ -1,55 +1,55 @@
----
-title: "RTO"
-type: concept
-tags:
-  - AWS
-  - Disaster Recovery
-  - High Availability
-  - Cloud Architecture
-sources:
-  - ctp-topic-66-exposing-the-differences-between-postgresql-rds-and-aurora
-last_updated: 2026-04-23
----
-
-## Overview
-RTO（Recovery Time Objective，恢复时间目标）是从系统故障发生到恢复正常运行所需的最大可接受时间。是灾备（DR）策略中的核心指标。
-
-## Definition
-- **RTO**：系统从故障中恢复的时间目标
-- 与 [[RPO]]（Recovery Point Objective，恢复点目标）共同构成灾备的两大核心指标
-
-## AWS Database RTO 对比
-
-| 数据库服务 | AZ 故障 RTO | 架构特点 |
-|-----------|------------|----------|
-| **Aurora** | ~30 秒 | 6 副本跨 3 AZ 共享集群卷 |
-| **RDS** | ~2 分钟 | EC2 + EBS 分离，Multi-AZ 备用节点 |
-| **传统自建** | 数小时 | 需手动恢复 |
-
-## RTO vs RPO
-
-| 指标 | 定义 | 衡量内容 |
-|------|------|----------|
-| **RTO** | 恢复时间目标 | 系统不可用的最大时长 |
-| **RPO** | 恢复点目标 | 可接受的最大数据丢失时长 |
-
-## Key Insights
-- Aurora 的低 RTO 源于其 6 副本跨 3 AZ 的共享集群卷架构，故障时无需重建数据
-- RDS 的 RTO 较高是因为需要备用节点接管并重新建立连接
-- RTO 优化需要考虑 DNS TTL、TCP Keep-Alive、连接池配置等多个层面
-- **[[LaunchDarkly]]** 是企业 RTO 优化的典型案例
-
-## Related Concepts
-- [[RPO]]：Recovery Point Objective，恢复点目标
-- [[Disaster Recovery]]：灾备策略
-- [[High Availability]]：高可用性
-- [[Amazon Aurora]]：Aurora 的 RTO 优势
-- [[Amazon RDS]]：RDS 的 RTO 特点
-- [[ctp-topic-66-exposing-the-differences-between-postgresql-rds-and-aurora]]：AWS 数据库 RTO 实测对比
-- [[ctp-topic-72-implementing-an-enterprise-dr-strategy-using-aws-backup]]：企业级灾备策略
-
-## Aliases
-- Recovery Time Objective
-- 恢复时间目标
-- RTO
-- MTTR（Mean Time To Recovery，与 RTO 相关但 MTTR 是实际测量值）
+---
+title: "RTO"
+type: concept
+tags:
+  - AWS
+  - Disaster Recovery
+  - High Availability
+  - Cloud Architecture
+sources:
+  - ctp-topic-66-exposing-the-differences-between-postgresql-rds-and-aurora
+last_updated: 2026-04-28
+---
+
+## Overview
+RTO（Recovery Time Objective，恢复时间目标）是从系统故障发生到恢复正常运行所需的最大可接受时间。是灾备（DR）策略中的核心指标。
+
+## Definition
+- **RTO**：系统从故障中恢复的时间目标
+- 与 [[RPO]]（Recovery Point Objective，恢复点目标）共同构成灾备的两大核心指标
+
+## AWS Database RTO 对比
+
+| 数据库服务 | AZ 故障 RTO | 架构特点 |
+|-----------|------------|----------|
+| **Aurora** | ~30 秒 | 6 副本跨 3 AZ 共享集群卷 |
+| **RDS** | ~2 分钟 | EC2 + EBS 分离，Multi-AZ 备用节点 |
+| **传统自建** | 数小时 | 需手动恢复 |
+
+## RTO vs RPO
+
+| 指标 | 定义 | 衡量内容 |
+|------|------|----------|
+| **RTO** | 恢复时间目标 | 系统不可用的最大时长 |
+| **RPO** | 恢复点目标 | 可接受的最大数据丢失时长 |
+
+## Key Insights
+- Aurora 的低 RTO 源于其 6 副本跨 3 AZ 的共享集群卷架构，故障时无需重建数据
+- RDS 的 RTO 较高是因为需要备用节点接管并重新建立连接
+- RTO 优化需要考虑 DNS TTL、TCP Keep-Alive、连接池配置等多个层面
+- **[[LaunchDarkly]]** 是企业 RTO 优化的典型案例
+
+## Related Concepts
+- [[RPO]]：Recovery Point Objective，恢复点目标
+- [[Disaster Recovery]]：灾备策略
+- [[High Availability]]：高可用性
+- [[Amazon Aurora]]：Aurora 的 RTO 优势
+- [[Amazon RDS]]：RDS 的 RTO 特点
+- [[ctp-topic-66-exposing-the-differences-between-postgresql-rds-and-aurora]]：AWS 数据库 RTO 实测对比
+- [[ctp-topic-72-implementing-an-enterprise-dr-strategy-using-aws-backup]]：企业级灾备策略
+
+## Aliases
+- Recovery Time Objective
+- 恢复时间目标
+- RTO
+- MTTR（Mean Time To Recovery，与 RTO 相关但 MTTR 是实际测量值）

wiki/concepts/Robotic-Framework.md

@@ -0,0 +1,28 @@
+---
+title: "Robotic Framework"
+type: concept
+tags: ["Automation", "Testing", "DevOps", "QA"]
+sources: ["learning-sessions-standard-amis-updates-20231205-160324-meeting-recording-2"]
+last_updated: 2026-05-08
+---
+
+## Definition
+Robotic Framework（机器人框架）是一种开源的自动化测试框架，在 Micro Focus AWS Landing Zone AMI 发布流程中用于自动化基本测试用例和验证，将单个 AMI 的验证时间从 3-4 天缩短至 60 分钟。
+
+## Impact
+- **传统验证**：3-4 天手动测试
+- **自动化验证**：60 分钟
+- **提升效率**：约 95% 时间节省
+
+## Use Case in AMI Pipeline
+在 AMI 发布前运行自动化验证，确保：
+- OS 启动正常
+- 网络配置正确
+- SSM Agent 连接可用
+- 安全工具正常运行
+- 域加入功能正常
+
+## Connections
+- [[Amazon-Machine-Image]] — Robotic Framework 验证的对象
+- [[Jenkins-Multi-Branch-Pipeline]] — Robotic Framework 集成在 Jenkins 流水线中
+- [[AWS-Landing-Zone]] — Robotic Framework 是 AMI 发布自动化的一部分

wiki/concepts/SSM-Patching.md

@@ -0,0 +1,26 @@
+---
+title: "SSM Patching"
+type: concept
+tags: ["AWS", "Patch-Management", "SSM", "Security"]
+sources: ["learning-sessions-standard-amis-updates-20231205-160324-meeting-recording-2"]
+last_updated: 2026-05-08
+---
+
+## Definition
+SSM Patching（SSM 补丁管理）是 AWS Systems Manager 提供的自动化补丁管理功能，通过补丁基准（Patch Baseline）和维护窗口（Maintenance Window）为长期运行的 EC2 实例按需打补丁，作为 AMI 刷新策略的补充方案。
+
+## Problem Solved
+- **长期运行实例**：无法频繁重建和刷新 AMI
+- **安全合规**：需要持续应用安全补丁
+- **手动打补丁**：耗时且易出错
+
+## Key Components
+- **Patch Baseline**：定义补丁审批规则（批准/拒绝）
+- **Patch Group**：按标签分组的实例集合
+- **Maintenance Window**：定义打补丁的时间窗口
+- **SSM Automation Document**：自动化补丁安装流程
+
+## Connections
+- [[AWS-SSM]] — SSM Patching 是 AWS Systems Manager 的功能之一
+- [[Amazon-Machine-Image]] — SSM Patching 补充而非替代 AMI 刷新
+- [[AWS-Landing-Zone]] — SSM Patching 是 LZ 运维自动化的组成部分

wiki/concepts/Software-Factory.md

@@ -0,0 +1,43 @@
+---
+title: "Software-Factory"
+type: concept
+tags: [DevOps, AWS, Shared-Services]
+sources: [ctp-topic-7-saas-landing-zone-design]
+last_updated: 2026-05-06
+---
+
+## Software-Factory
+
+企业级软件开发流水线平台集合，提供代码仓库、CI/CD、制品库等核心开发服务，作为共享服务向所有产品账户提供。
+
+## Definition
+
+Software Factory 是 SAS Landing Zone 共享服务账户层的核心服务群：
+- **定位**：集中式软件开发基础设施，供所有产品团队使用，避免各产品账户重复建设
+- **服务组成**：
+  - **45 个 Hub**：独立的开发/构建节点（Hub accounts）
+  - **Octane Hub**：Micro Focus ALM（Application Lifecycle Management）平台
+  - **Artifactory**：JFrog Artifactory 二进制制品库
+- **使用方式**：产品账户的开发工作通过这些服务进行构建、打包和制品管理
+
+## Role in SAS Landing Zone
+
+在 [[ctp-topic-7-saas-landing-zone-design]] 定义的 Shared Services 账户中：
+- **账户位置**：Software Factory Account（共享服务层）
+- **服务范围**：面向所有 Product Accounts 提供软件开发服务
+- **与 Octane Hub 关系**：Octane Hub 是 Software Factory 的核心组件之一，用于产品生命周期管理
+
+## Key Properties
+- **Type**: Shared DevOps Platform
+- **In SAS LZ Layer**: Shared Services Accounts
+- **Components**: 45 Hubs + Octane Hub + Artifactory
+- **Benefit**: 集中化开发服务，避免重复建设
+
+## Related Entities
+- [[Octane-Hub]] — Micro Focus ALM 平台
+- [[Gruntwork]] — 提供参考架构
+
+## Connections
+- [[ctp-topic-7-saas-landing-zone-design]] — SAS LZ 共享服务层组件
+- [[ctp-topic-14-octane-hub-on-aws-real-life-experience-moving-production-services-i]] — Octane Hub 迁移实践
+- [[ctp-topic-35-aws-landing-zone-design-refresher-saas-labs]] — 共享服务账户架构变更

wiki/concepts/Sort-Key.md

@@ -0,0 +1,40 @@
+---
+title: "Sort Key"
+type: concept
+tags:
+  - Data-Engineering
+  - Database
+  - AWS-Redshift
+  - Performance-Optimization
+last_updated: 2026-04-14
+---
+
+## Definition
+
+Sort Key（排序键）是数据仓库中用于确定数据在存储介质上物理排列顺序的列或列组合。通过预先对数据进行排序，Sort Key 可以显著提升范围查询、过滤和聚合操作的性能。
+
+## Key Characteristics
+
+- **物理排序**：数据按 Sort Key 列的值在磁盘上连续存储
+- **范围查询优化**：对于 `WHERE date BETWEEN ...` 类查询，只需扫描相关数据块
+- **ZONE MAP**：列式存储系统（如 Redshift）利用 Sort Key 构建 ZONE MAP，快速跳过不包含目标值的数据块
+- **单一 vs 复合**：
+  - **单一排序键（Compound Sort Key）**：按列顺序联合排序，支持前缀匹配查询
+  - **交错排序键（Interleaved Sort Key）**：各列权重相同，支持更灵活的查询模式，但维护成本更高
+
+## Use Cases
+
+- 时间序列数据的日期/时间列排序（典型选择）
+- 频繁过滤的高基数列
+- 需要加速 `ORDER BY`、`GROUP BY` 的列
+
+## Related Concepts
+
+- [[Distribution-Key]]：数据在集群节点间的分布方式
+- [[Columnar-Storage]]：列式存储使 Sort Key 优化成为可能
+- [[MPP]]：Sort Key 优化局部性，提升 MPP 节点内效率
+- [[Amazon-Redshift]]：Sort Key 是 Redshift 性能优化的核心手段之一
+
+## Sources
+
+- [[ctp-topic-68-introduction-to-redshift]]：Sort Key 在 Redshift 架构中的作用

wiki/concepts/Terraform-IaC.md

@@ -0,0 +1,46 @@
+---
+title: "Terraform-IaC"
+type: concept
+tags: [IaC, Terraform, AWS, Automation]
+sources: [ctp-topic-7-saas-landing-zone-design]
+last_updated: 2026-05-06
+---
+
+## Terraform-IaC
+
+使用 HashiCorp Terraform 实现基础设施即代码（Infrastructure as Code）的实践方法论。
+
+## Definition
+
+Terraform-IaC 是 SAS Landing Zone 自动化部署的核心支柱：
+- **核心原则**：所有 AWS 资源通过 Terraform 代码声明，无需手动 Console 操作
+- **工作方式**：声明式配置 → `terraform plan`（预览）→ `terraform apply`（执行）
+- **状态管理**：Terraform State 记录资源的当前状态，与实际环境保持同步
+- **GitOps 集成**：代码存储在 GitHub，通过 Git Hook 触发 CI/CD 流水线
+
+## Role in SAS Landing Zone
+
+在 [[ctp-topic-7-saas-landing-zone-design]] 定义的自动化部署链路中：
+- **每个账户独立仓库**：Core/Baseline/Shared Services/Product 每个账户拥有独立 GitHub 仓库管理 Terraform 代码
+- **TerraGrunt 封装**：使用 TerraGrunt 简化跨账户 Terraform 配置
+- **部署链路**：GitHub 代码变更 → GitHub Hook → Jenkins → Management VPC → Lambda → ECS Cluster → Terraform apply
+- **Staging 测试**：所有变更先在 Staging 环境测试，通过后才部署生产
+
+## Key Properties
+- **Type**: Infrastructure as Code Practice
+- **Tool**: Terraform + TerraGrunt
+- **Version Control**: GitHub repositories (one per account)
+- **CI/CD Integration**: Jenkins + GitHub webhooks
+- **In SAS LZ**: 端到端自动化部署的核心
+
+## Related Concepts
+- [[Infrastructure-as-Code]] — IaC 通用方法论
+- [[Terraform-Modules]] — 可复用 Terraform 模块
+- [[GitOps]] — Git 作为 IaC 的事实来源
+- [[TerraGrant]] — TerraGrunt（Terraform 封装工具）
+
+## Connections
+- [[ctp-topic-7-saas-landing-zone-design]] — SAS LZ IaC 部署方法
+- [[ctp-topic-1-gruntwork-landing-zone-architecture]] — Gruntwork 模块化的 Terraform 架构
+- [[ctp-topic-16-cross-account-terraform-modules]] — 跨账户 Terraform 模块中心化部署
+- [[ctp-topic-48-terraform-vs-terragrunt]] — Terraform vs TerraGrunt 深度对比

wiki/concepts/Transit-Gateway.md

@@ -0,0 +1,42 @@
+---
+title: "Transit Gateway"
+type: concept
+tags: [AWS, Networking, Multi-Account]
+sources: [ctp-topic-7-saas-landing-zone-design]
+last_updated: 2026-05-06
+---
+
+## Transit Gateway
+
+AWS Transit Gateway 是区域级网络中枢，用于简化多个 VPCs 和账户之间的网络互联互通。
+
+## Definition
+
+Transit Gateway 在 AWS Landing Zone 架构中扮演网络互联的核心角色：
+- **范围**：区域级（Regional），连接同一区域内所有账户的 VPCs
+- **功能**：Hub-and-Spoke 架构的中心节点，所有跨账户流量经由 Transit Gateway 路由
+- **与 Checkpoint 集成**：Transit Gateway 的流量通过 Checkpoint Appliance 进行安全监控
+
+## Role in SAS Landing Zone
+
+在 [[ctp-topic-7-saas-landing-zone-design]] 定义的 Network 账户中：
+- **部署位置**：Network Account
+- **连接范围**：连接 Core/Baseline/Shared Services/Product 所有账户的 VPCs
+- **安全监控**：Checkpoint Appliance 部署于 Transit Gateway 层面，按标签（Tagging Approach）监控跨账户流量
+- **访问控制**：资源必须携带特定标签（如 `internet-access=true`）才能访问互联网或 On-prem 网络
+
+## Key Properties
+- **Type**: Network Hub
+- **Scope**: Regional
+- **Architecture**: Hub-and-Spoke
+- **In SAS LZ**: Network Account 核心组件
+
+## Relationship to Checkpoint
+- Transit Gateway 负责路由
+- Checkpoint Appliance 负责流量安全检查（按标签策略）
+- 两者协同：路由 + 安全监控
+
+## Connections
+- [[ctp-topic-7-saas-landing-zone-design]] — SAS LZ Network 账户核心组件
+- [[ctp-topic-18-wide-area-networking-in-aws-cloud]] — 广域网（WAN）连接设计
+- [[ctp-topic-31-network-segregation-and-secure-access-to-the-new-aws-landing-zones]] — 网络分段与安全访问

wiki/concepts/WAF-Web-Application-Firewall.md

@@ -0,0 +1,46 @@
+---
+title: "WAF (Web Application Firewall)"
+type: concept
+tags: [AWS, Security, Networking]
+sources: [ctp-topic-7-saas-landing-zone-design]
+last_updated: 2026-05-06
+---
+
+## WAF (Web Application Firewall)
+
+AWS Web Application Firewall — Web 应用防火墙服务，监控和过滤进入 Web 应用的 HTTP/HTTPS 流量。
+
+## Definition
+
+WAF 是产品账户入站安全层的核心组件：
+- **功能**：通过规则（Rules）过滤恶意流量，保护 Web 应用免受 OWASP Top 10 等常见攻击
+- **部署位置**：产品账户，位于 CloudFront 和 Load Balancer 之后
+- **流量监控**：WAF 监控入站流量，可阻断 SQL 注入、XSS、CSRF 等攻击
+
+## Role in SAS Landing Zone
+
+在 [[ctp-topic-7-saas-landing-zone-design]] 定义的 Product Account 入站架构中：
+- **位置**：CloudFront → **WAF** → Load Balancer（公有子网）→ 工作负载（私有子网）
+- **功能**：实时监控入站流量，阻断异常请求
+- **可选 CloudFront**：CDN 层可选，但 WAF 是必须的安全层
+
+## Key Properties
+- **Type**: Security Service
+- **Layer**: Application Layer (L7)
+- **Position in stack**: After CDN/Before Application
+- **In SAS LZ**: 产品账户入站安全层
+
+## AWS WAF Capabilities
+- Managed rule groups (AWS managed, vendor managed)
+- IP blocking/rate limiting
+- Geographic restrictions
+- SQL injection and XSS protection
+- Bot control
+
+## Relationship to AWS Firewall Manager
+- [[AWS-Firewall-Manager]] 提供多账户 WAF 策略的统一管理
+- [[ctp-topic-55-aws-firewall-manager]] 覆盖 AWS Firewall Manager 的具体实践
+
+## Connections
+- [[ctp-topic-7-saas-landing-zone-design]] — SAS LZ 产品账户入站安全层
+- [[ctp-topic-55-aws-firewall-manager]] — AWS Firewall Manager 多账户 WAF 管理

wiki/concepts/high-availability.md

@@ -1,39 +1,39 @@
----
-title: High Availability (Cloud)
----
-
-# High Availability (Cloud)
-
-**High Availability (HA)** in cloud computing refers to systems designed to operate continuously without failure, typically by eliminating single points of failure and distributing workloads across redundant infrastructure.
-
-## Common Misconception
-
-> **Myth**: Cloud performance is unreliable.
-
-> **Reality**: Cloud providers offer high availability and redundancy.
-
-## Key HA Characteristics in Cloud
-
-- **Service Level Agreements (SLAs)**: Major cloud providers guarantee uptime exceeding **99.99%**
-- **Redundant Infrastructure**: Data and services are replicated across multiple geographic regions and availability zones
-- **Automated Failover**: Automatic switching to backup systems when primary systems fail
-- **Global Data Center Distribution**: Workloads distributed worldwide for geographic resilience
-- **Load Balancing**: Traffic distributed across multiple healthy instances
-
-## Benefits
-
-- Minimized downtime and business disruption
-- Improved user experience and reliability
-- Reduced financial impact of outages
-- Better disaster recovery posture
-
-## Related Concepts
-
-- [[Cloud Computing]]
-- [[Disaster Recovery]]
-- [[Cloud Migration]]
-- [[Multi-Cloud Strategy]]
-
-## Sources
-
-- [[The Myths and Misconceptions About Cloud Computing (LinkedIn)|the-myths-and-misconceptions-about-cloud-computing-linkedin]]
+---
+title: High Availability (Cloud)
+---
+
+# High Availability (Cloud)
+
+**High Availability (HA)** in cloud computing refers to systems designed to operate continuously without failure, typically by eliminating single points of failure and distributing workloads across redundant infrastructure.
+
+## Common Misconception
+
+> **Myth**: Cloud performance is unreliable.
+
+> **Reality**: Cloud providers offer high availability and redundancy.
+
+## Key HA Characteristics in Cloud
+
+- **Service Level Agreements (SLAs)**: Major cloud providers guarantee uptime exceeding **99.99%**
+- **Redundant Infrastructure**: Data and services are replicated across multiple geographic regions and availability zones
+- **Automated Failover**: Automatic switching to backup systems when primary systems fail
+- **Global Data Center Distribution**: Workloads distributed worldwide for geographic resilience
+- **Load Balancing**: Traffic distributed across multiple healthy instances
+
+## Benefits
+
+- Minimized downtime and business disruption
+- Improved user experience and reliability
+- Reduced financial impact of outages
+- Better disaster recovery posture
+
+## Related Concepts
+
+- [[Cloud Computing]]
+- [[Disaster Recovery]]
+- [[Cloud Migration]]
+- [[Multi-Cloud Strategy]]
+
+## Sources
+- [[The Myths and Misconceptions About Cloud Computing (LinkedIn)|the-myths-and-misconceptions-about-cloud-computing-linkedin]]
+- [[ctp-topic-72-implementing-an-enterprise-dr-strategy-using-aws-backup.md]]