diff --git a/Project/fonrey/DATA_MODEL/DATA_MODEL.md b/Project/fonrey/DATA_MODEL/DATA_MODEL.md
index bc76bef2..b03595c8 100644
--- a/Project/fonrey/DATA_MODEL/DATA_MODEL.md
+++ b/Project/fonrey/DATA_MODEL/DATA_MODEL.md
@@ -1,8 +1,8 @@
# Fonrey 房产经纪管理系统 — DATA MODEL 设计文档
> **作者**: Backend Architect
-> **版本**: v1.0
-> **日期**: 2026-04-24
+> **版本**: v1.3
+> **日期**: 2026-04-24（v1.1 修复 S1/S2/S4；v1.2 扩展 public schema；v1.3 §三 DDL 迁至 DATA_MODEL_PUBLIC.md，本文改为索引）
> **技术栈**: Django 4.x + PostgreSQL + django-tenants + Redis
> **设计目标**: 支撑 89,000+ 房源、多租户隔离、sub-100ms 查询、合规审计
@@ -13,18 +13,28 @@
### 1.1 多租户策略：Schema-per-Tenant
```
-┌─────────────────────────────────────────────────────────────┐
-│ PostgreSQL Instance │
-│ │
-│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │
-│ │ public schema│ │tenant_abc │ │tenant_xyz │ │
-│ │ (shared) │ │ schema │ │ schema │ │
-│ │ │ │ │ │ │ │
-│ │ - tenants │ │ - properties │ │ - properties │ │
-│ │ - domains │ │ - clients │ │ - clients │ │
-│ │ │ │ - complexes │ │ - complexes │ │
-│ └──────────────┘ └──────────────┘ └──────────────┘ │
-└─────────────────────────────────────────────────────────────┘
+┌──────────────────────────────────────────────────────────────────────┐
+│ PostgreSQL Instance │
+│ │
+│ ┌─────────────────────────┐ ┌──────────────┐ ┌──────────────┐ │
+│ │ public schema │ │ tenant_abc │ │ tenant_xyz │ │
+│ │ (平台运营层) │ │ schema │ │ schema │ │
+│ │ │ │ │ │ │ │
+│ │ - tenants │ │ - properties │ │ - properties │ │
+│ │ - domains │ │ - clients │ │ - clients │ │
+│ │ - tenant_status_logs │ │ - complexes │ │ - complexes │ │
+│ │ - platform_admins │ │ - staff │ │ - staff │ │
+│ │ - admin_mfa_devices │ │ - org_units │ │ - org_units │ │
+│ │ - admin_sessions │ │ - ... │ │ - ... │ │
+│ │ - ip_whitelist │ └──────────────┘ └──────────────┘ │
+│ │ - platform_audit_logs │ │
+│ │ - backup_schedules │ │
+│ │ - backup_records │ │
+│ │ - export_tasks │ │
+│ │ - system_versions │ │
+│ │ - upgrade_events │ │
+│ └─────────────────────────┘ │
+└──────────────────────────────────────────────────────────────────────┘
```
**选型理由**：
@@ -76,9 +86,28 @@
### 核心领域对象
+#### Public Schema（平台运营层）
+
+| 领域对象 | 表 | 业务说明 |
+|----------|-----|----------|
+| **Tenant（租户）** | `public.tenants` | 每家房产经纪公司一条记录，含状态机（creating/active/suspended/pending_delete/deleted）、套餐、联系人 |
+| **Domain（域名）** | `public.domains` | 子域名↔租户映射，支持多域名绑定，子域名创建后不可修改 |
+| **TenantStatusLog** | `public.tenant_status_logs` | 租户状态变更不可变审计（append-only） |
+| **PlatformAdmin** | `public.platform_admins` | 平台管理员账号，3 种角色：超级管理员/运营人员/只读审计员 |
+| **AdminMfaDevice** | `public.admin_mfa_devices` | 管理员 TOTP 设备（强制启用） |
+| **AdminSession** | `public.admin_sessions` | 登录会话（30 分钟超时，支持强制登出） |
+| **IpWhitelist** | `public.ip_whitelist` | 管理控制台 CIDR 白名单 |
+| **PlatformAuditLog** | `public.platform_audit_logs` | 所有写操作+高危操作审计（append-only，建议月度分区） |
+| **BackupSchedule** | `public.backup_schedules` | 全局/租户级定时备份计划（频率/保留数/存储目标） |
+| **BackupRecord** | `public.backup_records` | 备份任务执行记录（自动/手动/升级前/恢复前） |
+| **ExportTask** | `public.export_tasks` | 数据导出异步任务（CSV/JSON/SQL Dump，24h 下载链接） |
+| **SystemVersion** | `public.system_versions` | 平台版本历史，唯一 current 版本约束 |
+| **UpgradeEvent** | `public.upgrade_events` | 升级/回滚事件，含灰度租户维度进度快照 |
+
+#### Tenant Schema（租户业务层）
+
| 领域对象 | 表/子文档 | 业务说明 |
|----------|-----------|----------|
-| **Tenant（租户）** | `public.tenants` | 每家房产经纪公司对应一个租户，数据完全隔离（Schema-per-Tenant） |
| **OrgUnit（组织架构）** | `org_units` → [DATA_MODEL_ORG.md](./DATA_MODEL_ORG.md) | 树形组织架构（总部/区域/城市/大区/分公司/门店/团队/虚拟团队），物化路径存储，支持权限继承 |
| **Staff（员工）** | `staff` → [DATA_MODEL_ORG.md](./DATA_MODEL_ORG.md) | 经纪人/店长/经理，绑定组织节点，手机号加密存储，与账号（登录）分离 |
| **District（城区）** | `districts` → [DATA_MODEL_COMPLEX.md](./DATA_MODEL_COMPLEX.md) | 行政区划，如「静安区」，是区域体系的顶层节点 |
@@ -114,6 +143,7 @@ OrgUnit (组织架构)
| 子文档 | 覆盖模块 | 状态 |
|--------|----------|------|
+| [DATA_MODEL_PUBLIC.md](./DATA_MODEL_PUBLIC.md) | Public schema 平台运营层（tenants, domains, platform_admins, admin_sessions, audit_logs, backup, export, upgrade 共 13 张表） | ✅ 完成 |
| [DATA_MODEL_ORG.md](./DATA_MODEL_ORG.md) | 组织人事（org_units, staff, 异动/奖惩/教育/家庭等） | ✅ 完成 |
| [DATA_MODEL_COMPLEX.md](./DATA_MODEL_COMPLEX.md) | 楼盘/区域（districts, business_areas, complexes, buildings, room_units, schools 等） | ✅ 完成 |
| [DATA_MODEL_CLIENT.md](./DATA_MODEL_CLIENT.md) | 客源管理（clients, requirements, follow_logs, viewings, matches 等） | ✅ 完成 |
@@ -123,42 +153,41 @@ OrgUnit (组织架构)
## 三、公共 Schema（Shared / Public）
+> **权威源**：完整 DDL 已迁至 [`DATA_MODEL_PUBLIC.md`](./DATA_MODEL_PUBLIC.md)，本节仅保留摘要索引。
+> **覆盖范围**：`public` schema 存储平台运营层数据——租户注册、管理员账号、审计日志、备份/导出任务、版本升级记录（共 13 张表）。
+> **设计依据**：系统管理模块 PRD（`PRD/系统管理/系统管理模块PRD.md`）。
-```sql
--- ============================================================
--- 文件: shared_schema.sql
--- 用途: django-tenants 公共 Schema，存放租户注册信息
--- ============================================================
+### 表清单（开发以 DATA_MODEL_PUBLIC.md 为准）
--- 租户表（每家房产公司一条记录）
-CREATE TABLE public.tenants (
- id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
- schema_name VARCHAR(63) UNIQUE NOT NULL, -- PG schema 名，最长 63 字符
- name VARCHAR(255) NOT NULL, -- 公司名称
- short_name VARCHAR(100), -- 简称/品牌名
- created_at TIMESTAMPTZ NOT NULL DEFAULT NOW(),
- updated_at TIMESTAMPTZ NOT NULL DEFAULT NOW(),
- is_active BOOLEAN NOT NULL DEFAULT TRUE,
- paid_until DATE, -- 订阅到期日
- on_trial BOOLEAN NOT NULL DEFAULT TRUE,
- extra JSONB NOT NULL DEFAULT '{}' -- 预留扩展字段
-);
+| 表名 | 说明 | 节 |
+|------|------|----|
+| `public.tenants` | 租户主表（django-tenants 核心，状态机 6 态） | §2.1 |
+| `public.domains` | 域名↔租户映射（支持多域名，子域名不可修改） | §2.1 |
+| `public.tenant_status_logs` | 租户状态变更不可变审计日志（append-only） | §2.1 |
+| `public.platform_admins` | 平台管理员账号（super_admin/ops_operator/read_only_auditor） | §2.2 |
+| `public.admin_mfa_devices` | 管理员 TOTP MFA 设备（强制启用） | §2.2 |
+| `public.admin_sessions` | 管理员登录会话（30 min 滚动超时，支持强制登出） | §2.2 |
+| `public.ip_whitelist` | 管理控制台 CIDR 白名单 | §2.2 |
+| `public.platform_audit_logs` | 所有写操作+高危操作审计（append-only，建议月度分区） | §2.3 |
+| `public.backup_schedules` | 全局/租户级定时备份计划（NULL tenant_id = 全局默认） | §2.4 |
+| `public.backup_records` | 备份任务执行记录（auto/manual/pre_upgrade/pre_restore） | §2.4 |
+| `public.export_tasks` | 数据导出异步任务（CSV/JSON/SQL Dump，24h 下载链接） | §2.4 |
+| `public.system_versions` | 平台版本历史，部分唯一索引保证唯一 current | §2.5 |
+| `public.upgrade_events` | 升级/回滚事件，`tenant_progress` JSONB 快照各租户状态 | §2.5 |
--- 域名映射表（支持多域名绑定一个租户）
-CREATE TABLE public.domains (
- id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
- domain VARCHAR(253) UNIQUE NOT NULL, -- 含子域名的完整域名
- tenant_id UUID NOT NULL REFERENCES public.tenants(id) ON DELETE CASCADE,
- is_primary BOOLEAN NOT NULL DEFAULT FALSE,
- created_at TIMESTAMPTZ NOT NULL DEFAULT NOW()
-);
-
-CREATE INDEX idx_domains_tenant ON public.domains(tenant_id);
-CREATE INDEX idx_domains_primary ON public.domains(tenant_id) WHERE is_primary = TRUE;
-```
+**关键约束提示**：
+- `tenant_status_logs` / `platform_audit_logs` **无 deleted_at**，禁止 UPDATE/DELETE，append-only
+- `public.tenants.schema_name` 创建后**不可修改**
+- `public.tenants` 不再使用 `is_active` boolean，改用 6 态 `status` 枚举
+- `platform_admins` 与租户 `staff` **完全独立**，不共享 auth 系统
+- `system_versions` 通过部分唯一索引确保全局只有一个 `status='current'`
---
+
+
+
+
## 四、租户 Schema（Tenant Schema）
以下所有表均在每个租户的独立 Schema 内创建。
diff --git a/Project/fonrey/DATA_MODEL/DATA_MODEL_PUBLIC.md b/Project/fonrey/DATA_MODEL/DATA_MODEL_PUBLIC.md
new file mode 100644
index 00000000..b4eb4050
--- /dev/null
+++ b/Project/fonrey/DATA_MODEL/DATA_MODEL_PUBLIC.md
@@ -0,0 +1,488 @@
+# Fonrey — Public Schema 数据模型
+
+> **作者**: Backend Architect
+> **版本**: v1.0
+> **日期**: 2026-04-24
+> **权威源**: 本文件是 `public` schema 所有表的唯一权威定义
+> **设计依据**: 系统管理模块 PRD（`PRD/系统管理/系统管理模块PRD.md`）
+> **索引文档**: [`DATA_MODEL.md §三`](./DATA_MODEL.md)（仅保留摘要索引，开发以本文件为准）
+
+---
+
+## 一、概览
+
+`public` schema 存储**平台运营层**数据，与各租户的业务 schema 完全隔离。
+
+### 架构定位
+
+```
+PostgreSQL Instance
+│
+├── public schema（平台运营层）← 本文件覆盖
+│ ├── tenants 租户注册与生命周期
+│ ├── domains 域名路由
+│ ├── tenant_status_logs 状态变更审计
+│ ├── platform_admins 管理员账号
+│ ├── admin_mfa_devices TOTP 设备
+│ ├── admin_sessions 登录会话
+│ ├── ip_whitelist 访问控制
+│ ├── platform_audit_logs 操作审计
+│ ├── backup_schedules 备份计划
+│ ├── backup_records 备份记录
+│ ├── export_tasks 数据导出
+│ ├── system_versions 版本历史
+│ └── upgrade_events 升级记录
+│
+├── tenant_abc schema（租户业务层，见各子文档）
+└── tenant_xyz schema
+```
+
+### 表清单
+
+| 表名 | 说明 | 节 |
+|------|------|----|
+| `public.tenants` | 租户主表（每家房产公司一条记录） | §2.1 |
+| `public.domains` | 域名↔租户映射（多域名支持） | §2.1 |
+| `public.tenant_status_logs` | 租户状态变更不可变审计日志 | §2.1 |
+| `public.platform_admins` | 平台管理员账号（3 种角色） | §2.2 |
+| `public.admin_mfa_devices` | 管理员 TOTP MFA 设备（强制启用） | §2.2 |
+| `public.admin_sessions` | 管理员登录会话（30 min 超时，支持强制登出） | §2.2 |
+| `public.ip_whitelist` | 管理控制台 CIDR 白名单 | §2.2 |
+| `public.platform_audit_logs` | 所有写操作+高危操作审计（append-only，建议月度分区） | §2.3 |
+| `public.backup_schedules` | 全局/租户级定时备份计划 | §2.4 |
+| `public.backup_records` | 备份任务执行记录（自动/手动/升级前/恢复前） | §2.4 |
+| `public.export_tasks` | 数据导出异步任务（CSV/JSON/SQL Dump） | §2.4 |
+| `public.system_versions` | 平台版本历史，唯一 current 约束 | §2.5 |
+| `public.upgrade_events` | 升级/回滚事件，含灰度租户维度进度快照 | §2.5 |
+
+---
+
+## 二、DDL 定义
+
+### 2.1 租户管理
+
+```sql
+-- ============================================================
+-- 文件: shared_schema.sql
+-- 用途: django-tenants 公共 Schema，存放平台运营层数据
+-- 设计依据: 系统管理模块 PRD v1.0
+-- ============================================================
+
+-- ────────────────────────────────────────────────────────────
+-- 1. 租户管理
+-- ────────────────────────────────────────────────────────────
+
+-- 租户状态枚举（生命周期状态机，见 PRD §9.1）
+-- creating → active ←→ suspended → pending_delete → deleted
+-- ↑ 硬删除直接到 deleted
+
+-- 租户主表（每家房产经纪公司一条记录）
+CREATE TABLE public.tenants (
+ id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
+ schema_name VARCHAR(63) UNIQUE NOT NULL, -- PG schema 名，最长 63 字符，创建后不可修改
+ name VARCHAR(255) NOT NULL, -- 公司名称
+ short_name VARCHAR(100), -- 简称/品牌名
+ contact_name VARCHAR(100) NOT NULL, -- 主联系人姓名
+ contact_email VARCHAR(254) NOT NULL, -- 联系邮箱（接收通知/欢迎邮件）
+ region VARCHAR(100), -- 所在地区（省市，如「上海市」）
+ plan VARCHAR(20) NOT NULL DEFAULT 'basic'
+ CHECK (plan IN ('basic','professional','enterprise')),
+
+ -- 状态机
+ status VARCHAR(20) NOT NULL DEFAULT 'creating'
+ CHECK (status IN ('creating','active','suspended','pending_delete','deleted','failed')),
+ suspended_until TIMESTAMPTZ, -- NULL = 永久挂起，非 NULL = Celery Beat 定时恢复
+ suspended_reason VARCHAR(50)
+ CHECK (suspended_reason IN ('overdue','violation','requested','other')),
+ deleted_at TIMESTAMPTZ, -- 软删除时间戳；硬删除直接物理删除行
+
+ -- 订阅
+ paid_until DATE, -- 订阅到期日
+ on_trial BOOLEAN NOT NULL DEFAULT TRUE,
+
+ -- 灰度升级
+ is_canary BOOLEAN NOT NULL DEFAULT FALSE, -- TRUE = 内测租户，参与灰度升级
+
+ -- 元数据
+ created_at TIMESTAMPTZ NOT NULL DEFAULT NOW(),
+ updated_at TIMESTAMPTZ NOT NULL DEFAULT NOW(),
+ created_by UUID, -- 创建该租户的管理员 ID（可 NULL，初始化时）
+ extra JSONB NOT NULL DEFAULT '{}' -- 预留扩展字段
+);
+
+CREATE INDEX idx_tenants_status ON public.tenants(status);
+CREATE INDEX idx_tenants_suspended_until ON public.tenants(suspended_until)
+ WHERE status = 'suspended' AND suspended_until IS NOT NULL;
+CREATE INDEX idx_tenants_canary ON public.tenants(is_canary) WHERE is_canary = TRUE;
+CREATE INDEX idx_tenants_pending_delete ON public.tenants(deleted_at)
+ WHERE status = 'pending_delete';
+
+-- 域名映射表（支持多域名绑定一个租户，子域名创建后不可修改）
+CREATE TABLE public.domains (
+ id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
+ domain VARCHAR(253) UNIQUE NOT NULL, -- 含子域名的完整域名（如 abc.platform.com）
+ tenant_id UUID NOT NULL REFERENCES public.tenants(id) ON DELETE CASCADE,
+ is_primary BOOLEAN NOT NULL DEFAULT FALSE,
+ created_at TIMESTAMPTZ NOT NULL DEFAULT NOW()
+);
+
+CREATE INDEX idx_domains_tenant ON public.domains(tenant_id);
+CREATE UNIQUE INDEX idx_domains_primary ON public.domains(tenant_id) WHERE is_primary = TRUE;
+
+-- 租户状态变更日志（append-only，不可删除）
+-- 记录所有 status 变更：creating→active / active→suspended / suspended→active / →pending_delete / →deleted
+CREATE TABLE public.tenant_status_logs (
+ id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
+ tenant_id UUID NOT NULL REFERENCES public.tenants(id) ON DELETE CASCADE,
+ from_status VARCHAR(20), -- NULL 表示初始创建
+ to_status VARCHAR(20) NOT NULL,
+ reason TEXT,
+ operator_id UUID, -- 操作管理员 ID；NULL = 系统自动（Celery）
+ operator_name VARCHAR(100), -- 快照，防止管理员被删后失去可追溯性
+ created_at TIMESTAMPTZ NOT NULL DEFAULT NOW()
+ -- 无 deleted_at，无 UPDATE，append-only
+);
+
+CREATE INDEX idx_tenant_status_logs_tenant ON public.tenant_status_logs(tenant_id, created_at DESC);
+```
+
+### 2.2 平台管理员
+
+```sql
+-- ────────────────────────────────────────────────────────────
+-- 2. 平台管理员
+-- ────────────────────────────────────────────────────────────
+
+-- 管理员账号（与租户 staff 完全独立，存于 public schema）
+CREATE TABLE public.platform_admins (
+ id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
+ username VARCHAR(150) UNIQUE NOT NULL,
+ email VARCHAR(254) UNIQUE NOT NULL,
+ display_name VARCHAR(100) NOT NULL,
+ password_hash VARCHAR(255) NOT NULL, -- Django PBKDF2 / Argon2 哈希
+ role VARCHAR(20) NOT NULL
+ CHECK (role IN ('super_admin','ops_operator','read_only_auditor')),
+ is_active BOOLEAN NOT NULL DEFAULT TRUE,
+ mfa_enabled BOOLEAN NOT NULL DEFAULT FALSE, -- 首次登录前为 FALSE，配置 TOTP 后变 TRUE
+ last_login_at TIMESTAMPTZ,
+ created_at TIMESTAMPTZ NOT NULL DEFAULT NOW(),
+ updated_at TIMESTAMPTZ NOT NULL DEFAULT NOW(),
+ created_by UUID REFERENCES public.platform_admins(id) ON DELETE SET NULL
+);
+
+CREATE INDEX idx_platform_admins_role ON public.platform_admins(role) WHERE is_active = TRUE;
+
+-- MFA 设备（TOTP，每管理员可注册多个设备，但通常一个）
+CREATE TABLE public.admin_mfa_devices (
+ id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
+ admin_id UUID NOT NULL REFERENCES public.platform_admins(id) ON DELETE CASCADE,
+ device_name VARCHAR(100) NOT NULL DEFAULT 'Authenticator App',
+ totp_secret VARCHAR(255) NOT NULL, -- Base32 加密存储
+ is_confirmed BOOLEAN NOT NULL DEFAULT FALSE, -- 首次验证通过后置 TRUE
+ created_at TIMESTAMPTZ NOT NULL DEFAULT NOW(),
+ last_used_at TIMESTAMPTZ
+);
+
+CREATE INDEX idx_admin_mfa_devices_admin ON public.admin_mfa_devices(admin_id)
+ WHERE is_confirmed = TRUE;
+
+-- 管理员登录会话（支持强制登出）
+CREATE TABLE public.admin_sessions (
+ id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
+ admin_id UUID NOT NULL REFERENCES public.platform_admins(id) ON DELETE CASCADE,
+ session_token VARCHAR(255) UNIQUE NOT NULL, -- 随机安全令牌
+ ip_address INET NOT NULL,
+ user_agent TEXT,
+ is_active BOOLEAN NOT NULL DEFAULT TRUE,
+ created_at TIMESTAMPTZ NOT NULL DEFAULT NOW(),
+ expires_at TIMESTAMPTZ NOT NULL, -- 默认 NOW() + 30 分钟，活动时滚动续期
+ revoked_at TIMESTAMPTZ, -- 强制登出时记录
+ revoked_by UUID REFERENCES public.platform_admins(id) ON DELETE SET NULL
+);
+
+CREATE INDEX idx_admin_sessions_admin ON public.admin_sessions(admin_id) WHERE is_active = TRUE;
+CREATE INDEX idx_admin_sessions_expires ON public.admin_sessions(expires_at) WHERE is_active = TRUE;
+
+-- IP 白名单（管理控制台访问限制）
+CREATE TABLE public.ip_whitelist (
+ id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
+ cidr CIDR NOT NULL, -- 如 203.0.113.0/24 或 203.0.113.5/32
+ label VARCHAR(100), -- 备注，如「上海办公室」
+ is_active BOOLEAN NOT NULL DEFAULT TRUE,
+ created_at TIMESTAMPTZ NOT NULL DEFAULT NOW(),
+ created_by UUID REFERENCES public.platform_admins(id) ON DELETE SET NULL
+);
+
+CREATE INDEX idx_ip_whitelist_active ON public.ip_whitelist(cidr) WHERE is_active = TRUE;
+```
+
+### 2.3 审计日志（append-only）
+
+```sql
+-- ────────────────────────────────────────────────────────────
+-- 3. 审计日志（append-only）
+-- ────────────────────────────────────────────────────────────
+
+-- 平台操作审计日志（所有写操作 + 高危操作，无 deleted_at，无 UPDATE）
+CREATE TABLE public.platform_audit_logs (
+ id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
+ operator_id UUID, -- 管理员 ID；NULL 表示系统自动操作
+ operator_name VARCHAR(100), -- 快照（防止账号删除后失去溯源）
+ action_type VARCHAR(50) NOT NULL,
+ -- CREATE_TENANT | SUSPEND_TENANT | RESUME_TENANT | DELETE_TENANT | HARD_DELETE_TENANT
+ -- RESTORE_DATA | TRIGGER_BACKUP | SYSTEM_UPGRADE | ROLLBACK
+ -- RESET_PASSWORD | CREATE_ADMIN | DEACTIVATE_ADMIN | FORCE_LOGOUT
+ -- UPDATE_IP_WHITELIST | UPDATE_BACKUP_SCHEDULE | EXPORT_DATA | ...
+ target_type VARCHAR(30) NOT NULL, -- Tenant | User | System | Backup | Admin
+ target_id VARCHAR(255), -- 操作对象 ID（UUID 或其他）
+ target_name VARCHAR(255), -- 操作对象可读名称（快照）
+ payload_summary TEXT, -- 操作内容摘要（非敏感字段）
+ result VARCHAR(10) NOT NULL DEFAULT 'SUCCESS'
+ CHECK (result IN ('SUCCESS','FAILED')),
+ error_message TEXT,
+ ip_address INET,
+ created_at TIMESTAMPTZ NOT NULL DEFAULT NOW()
+ -- 无 deleted_at，无 UPDATE；建议按月 RANGE 分区
+);
+
+CREATE INDEX idx_audit_logs_operator ON public.platform_audit_logs(operator_id, created_at DESC);
+CREATE INDEX idx_audit_logs_action ON public.platform_audit_logs(action_type, created_at DESC);
+CREATE INDEX idx_audit_logs_target ON public.platform_audit_logs(target_type, target_id, created_at DESC);
+CREATE INDEX idx_audit_logs_created ON public.platform_audit_logs(created_at DESC);
+```
+
+### 2.4 备份与导出
+
+```sql
+-- ────────────────────────────────────────────────────────────
+-- 4. 备份与导出
+-- ────────────────────────────────────────────────────────────
+
+-- 定时备份计划（全局策略 + 租户覆盖策略）
+CREATE TABLE public.backup_schedules (
+ id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
+ tenant_id UUID REFERENCES public.tenants(id) ON DELETE CASCADE,
+ -- NULL = 全局默认计划；非 NULL = 该租户的独立计划（覆盖全局）
+ frequency VARCHAR(10) NOT NULL DEFAULT 'daily'
+ CHECK (frequency IN ('hourly','daily','weekly')),
+ scheduled_time TIME NOT NULL DEFAULT '02:00', -- 执行时间窗口（UTC）
+ retention_count INTEGER NOT NULL DEFAULT 10, -- 最多保留 N 个备份版本
+ storage_target VARCHAR(20) NOT NULL DEFAULT 'r2'
+ CHECK (storage_target IN ('local','s3','r2','gcs')),
+ is_active BOOLEAN NOT NULL DEFAULT TRUE,
+ created_at TIMESTAMPTZ NOT NULL DEFAULT NOW(),
+ updated_at TIMESTAMPTZ NOT NULL DEFAULT NOW(),
+ created_by UUID REFERENCES public.platform_admins(id) ON DELETE SET NULL,
+ UNIQUE (tenant_id) -- 每个租户最多一条独立计划；NULL tenant_id 用应用层保证全局唯一
+);
+
+-- 备份任务执行记录
+CREATE TABLE public.backup_records (
+ id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
+ tenant_id UUID NOT NULL REFERENCES public.tenants(id) ON DELETE CASCADE,
+ trigger_type VARCHAR(10) NOT NULL
+ CHECK (trigger_type IN ('auto','manual','pre_upgrade','pre_restore')),
+ status VARCHAR(15) NOT NULL DEFAULT 'pending'
+ CHECK (status IN ('pending','in_progress','success','failed')),
+ storage_target VARCHAR(20) NOT NULL,
+ storage_path TEXT, -- R2/S3 存储路径
+ size_bytes BIGINT, -- 备份包大小
+ started_at TIMESTAMPTZ,
+ completed_at TIMESTAMPTZ,
+ error_message TEXT,
+ triggered_by UUID REFERENCES public.platform_admins(id) ON DELETE SET NULL,
+ upgrade_event_id UUID, -- 关联升级事件（pre_upgrade 类型）
+ created_at TIMESTAMPTZ NOT NULL DEFAULT NOW()
+);
+
+CREATE INDEX idx_backup_records_tenant ON public.backup_records(tenant_id, created_at DESC);
+CREATE INDEX idx_backup_records_status ON public.backup_records(status)
+ WHERE status IN ('pending','in_progress');
+
+-- 数据导出任务（异步 Celery 执行）
+CREATE TABLE public.export_tasks (
+ id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
+ tenant_id UUID NOT NULL REFERENCES public.tenants(id) ON DELETE CASCADE,
+ requested_by UUID REFERENCES public.platform_admins(id) ON DELETE SET NULL,
+ modules TEXT[] NOT NULL,
+ -- 'clients' | 'properties' | 'transactions' | 'system_config' | 'all'
+ format VARCHAR(10) NOT NULL
+ CHECK (format IN ('csv','json','sql_dump')),
+ status VARCHAR(15) NOT NULL DEFAULT 'pending'
+ CHECK (status IN ('pending','in_progress','done','failed')),
+ storage_path TEXT, -- R2 临时目录路径
+ download_url TEXT, -- 带签名下载链接
+ expires_at TIMESTAMPTZ, -- 下载链接有效期（默认 24 小时）
+ size_bytes BIGINT,
+ started_at TIMESTAMPTZ,
+ completed_at TIMESTAMPTZ,
+ error_message TEXT,
+ created_at TIMESTAMPTZ NOT NULL DEFAULT NOW()
+);
+
+CREATE INDEX idx_export_tasks_tenant ON public.export_tasks(tenant_id, created_at DESC);
+CREATE INDEX idx_export_tasks_status ON public.export_tasks(status)
+ WHERE status IN ('pending','in_progress');
+```
+
+### 2.5 版本升级管理
+
+```sql
+-- ────────────────────────────────────────────────────────────
+-- 5. 版本升级管理
+-- ────────────────────────────────────────────────────────────
+
+-- 平台版本历史
+CREATE TABLE public.system_versions (
+ id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
+ version_number VARCHAR(50) UNIQUE NOT NULL, -- 如 v2.3.1
+ release_notes TEXT,
+ artifact_url TEXT, -- 制品库地址
+ status VARCHAR(15) NOT NULL DEFAULT 'previous'
+ CHECK (status IN ('current','previous','archived')),
+ released_at TIMESTAMPTZ NOT NULL DEFAULT NOW(),
+ created_by UUID REFERENCES public.platform_admins(id) ON DELETE SET NULL
+);
+
+CREATE UNIQUE INDEX idx_system_versions_current ON public.system_versions(status)
+ WHERE status = 'current'; -- 全局只允许一个 current 版本
+
+-- 升级事件（每次执行升级或回滚对应一条记录）
+CREATE TABLE public.upgrade_events (
+ id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
+ from_version_id UUID REFERENCES public.system_versions(id) ON DELETE SET NULL,
+ to_version_id UUID NOT NULL REFERENCES public.system_versions(id) ON DELETE RESTRICT,
+ event_type VARCHAR(10) NOT NULL
+ CHECK (event_type IN ('upgrade','rollback')),
+ strategy VARCHAR(10) NOT NULL DEFAULT 'full'
+ CHECK (strategy IN ('full','canary')), -- full = 全量，canary = 灰度
+ status VARCHAR(15) NOT NULL DEFAULT 'pending'
+ CHECK (status IN ('pending','health_check','in_progress','success','failed','rolled_back')),
+
+ -- 升级进度：每个租户的状态存为 JSONB 数组
+ -- [{tenant_id, tenant_name, status, started_at, completed_at, error}]
+ tenant_progress JSONB NOT NULL DEFAULT '[]',
+
+ -- 回滚触发条件
+ rollback_reason TEXT,
+ incident_report TEXT, -- 回滚后生成的事件报告
+
+ started_at TIMESTAMPTZ,
+ completed_at TIMESTAMPTZ,
+ initiated_by UUID REFERENCES public.platform_admins(id) ON DELETE SET NULL,
+ created_at TIMESTAMPTZ NOT NULL DEFAULT NOW()
+);
+
+CREATE INDEX idx_upgrade_events_status ON public.upgrade_events(status, created_at DESC);
+```
+
+---
+
+## 三、关键约束与禁止操作
+
+| 规则 | 说明 |
+|------|------|
+| `tenant_status_logs` append-only | 禁止 UPDATE / DELETE；状态机变更只追加新行 |
+| `platform_audit_logs` append-only | 禁止 UPDATE / DELETE；建议按月 RANGE 分区 |
+| `public.tenants.schema_name` 不可修改 | 创建后禁止 UPDATE，PG schema 绑定 |
+| `public.domains.domain` 不可修改 | 子域名创建后禁止 UPDATE |
+| `system_versions` 唯一 current | `idx_system_versions_current` 部分唯一索引保证全局只有一个 `status='current'` |
+| `backup_schedules.tenant_id` UNIQUE | 每个租户最多一条独立计划；`NULL` 全局计划由应用层保证唯一 |
+| `platform_admins` 与 `staff` 完全独立 | 不共享表、不共享 auth 系统 |
+| MFA 强制 | `platform_admins.mfa_enabled` 在首次 TOTP 确认后才变 TRUE；登录流必须检查 |
+| `admin_sessions` 30 分钟滚动超时 | 应用层每次活跃请求更新 `expires_at = NOW() + 30min` |
+
+---
+
+## 四、状态机
+
+### 4.1 租户生命周期
+
+```
+creating ──(初始化完成)──► active
+active ──(逾期/违规/申请)──► suspended ──(恢复条件满足)──► active
+active ──(申请注销)──► pending_delete ──(30天后/管理员确认)──► deleted
+suspended ──(申请注销)──► pending_delete
+creating ──(初始化失败)──► failed
+```
+
+**字段映射**：
+- `status` 枚举：`creating | active | suspended | pending_delete | deleted | failed`
+- `suspended_until = NULL`：永久挂起；`suspended_until IS NOT NULL`：Celery Beat 定时自动恢复
+- `deleted_at`：软删除时间戳；硬删除时物理删除整行
+
+### 4.2 升级事件状态
+
+```
+pending → health_check → in_progress → success
+ └─► failed → rolled_back
+```
+
+---
+
+## 五、查询模式
+
+### 5.1 常用查询
+
+```sql
+-- 查询所有活跃租户
+SELECT id, name, plan, paid_until
+FROM public.tenants
+WHERE status = 'active'
+ORDER BY created_at DESC;
+
+-- 查询即将到期的租户（7 天内）
+SELECT id, name, contact_email, paid_until
+FROM public.tenants
+WHERE status = 'active'
+ AND paid_until BETWEEN CURRENT_DATE AND CURRENT_DATE + 7;
+
+-- 查询灰度租户（canary 升级目标）
+SELECT id, schema_name, name
+FROM public.tenants
+WHERE is_canary = TRUE AND status = 'active';
+
+-- 查询某租户所有状态变更历史
+SELECT from_status, to_status, reason, operator_name, created_at
+FROM public.tenant_status_logs
+WHERE tenant_id = $1
+ORDER BY created_at DESC;
+
+-- 查询待自动恢复的挂起租户（Celery Beat 使用）
+SELECT id, schema_name, name
+FROM public.tenants
+WHERE status = 'suspended'
+ AND suspended_until IS NOT NULL
+ AND suspended_until <= NOW();
+
+-- 查询某管理员近 30 天的审计记录
+SELECT action_type, target_type, target_name, result, created_at
+FROM public.platform_audit_logs
+WHERE operator_id = $1
+ AND created_at >= NOW() - INTERVAL '30 days'
+ORDER BY created_at DESC;
+
+-- 查询进行中的备份任务
+SELECT br.id, t.name AS tenant_name, br.trigger_type, br.started_at
+FROM public.backup_records br
+JOIN public.tenants t ON t.id = br.tenant_id
+WHERE br.status IN ('pending', 'in_progress')
+ORDER BY br.created_at DESC;
+```
+
+### 5.2 禁止查询
+
+| 禁止操作 | 原因 |
+|----------|------|
+| `UPDATE public.tenant_status_logs` | append-only 审计表 |
+| `DELETE FROM public.platform_audit_logs` | append-only 审计表 |
+| `UPDATE public.tenants SET schema_name = ...` | schema 名绑定 PG 物理 schema |
+| `UPDATE public.domains SET domain = ...` | 域名路由不可变 |
+
+---
+
+## 六、版本历史
+
+| 版本 | 日期 | 变更 |
+|------|------|------|
+| v1.0 | 2026-04-24 | 从 `DATA_MODEL.md §三` 独立拆分；内容等价于 v1.2 DATA_MODEL.md §三 |
diff --git a/Project/fonrey/DATA_MODEL/diagram/fonrey-data-model.xml b/Project/fonrey/DATA_MODEL/diagram/fonrey-data-model.xml
index 5a660db1..3aed24a7 100644
--- a/Project/fonrey/DATA_MODEL/diagram/fonrey-data-model.xml
+++ b/Project/fonrey/DATA_MODEL/diagram/fonrey-data-model.xml
@@ -499,6 +499,247 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/wiki/concepts/Canary-Deployment.md b/wiki/concepts/Canary-Deployment.md
new file mode 100644
index 00000000..9bb4bc07
--- /dev/null
+++ b/wiki/concepts/Canary-Deployment.md
@@ -0,0 +1,56 @@
+---
+title: "Canary Deployment"
+type: concept
+tags: [DevOps, Deployment, Kubernetes, ECS, AWS]
+sources: [learning-sessions-ecs-deployment-using-iac-20230808-183322-meeting-recording]
+last_updated: 2026-05-05
+---
+
+# Canary Deployment
+
+## Definition
+金丝雀部署（Canary Deployment）是一种软件发布策略，通过将新版本逐步推向一小部分用户来降低风险——在新版本全面推广前，先将少量流量导向新版本，观察其行为和性能，验证无误后再逐步扩大比例。
+
+## Core Mechanism
+1. **流量分割**：将用户流量按比例分割（如 5%/10%/50%/100%）
+2. **逐步提升**：从低比例开始，逐步增加新版本流量
+3. **快速回滚**：发现问题时，立即将流量切回旧版本
+
+## Implementation in AWS
+
+### ECS (Elastic Container Service)
+ECS 模块支持金丝雀部署，通过 Target Group 权重调整实现流量控制：
+- 创建新旧两个 Task Definition
+- 通过 ALB/NLB 的 Target Group 逐步调整权重
+- 结合 CloudWatch 监控自动决策扩缩比例
+
+### EKS (Elastic Kubernetes Service)
+Kubernetes 原生支持金丝雀部署，通过以下机制：
+- `ReplicaSet` 控制新旧版本副本数
+- `Service` 选择器配合金丝雀标签
+- Argo Rollouts 等高级工具提供声明式金丝雀策略
+
+### AWS Tools
+- **AWS CodeDeploy**：原生支持 ECS 和 Lambda 的金丝雀部署策略
+- **ALB Target Groups**：权重路由实现流量分割
+- **CloudWatch**：金丝雀指标监控
+
+## Comparison with Other Deployment Strategies
+
+| 策略 | 风险 | 成本 | 适用场景 |
+|------|------|------|----------|
+| **Blue-Green** | 中 | 高（双倍资源） | 快速回滚需求 |
+| **Canary** | 低 | 中 | 生产验证 |
+| **Rolling** | 中 | 低 | 资源受限环境 |
+| **A/B Testing** | 低 | 中 | 功能验证 |
+
+## Key Metrics to Monitor
+- 错误率（5xx）
+- 延迟（P50/P95/P99）
+- 业务指标（转化率/点击率）
+- 资源利用率
+
+## Related Concepts
+- [[Blue-Green-Deployment]]：双环境切换策略
+- [[ECS-Module-Deployment]]：ECS 场景的模块化部署
+- [[Infrastructure-as-Code]]：部署自动化基础
diff --git a/wiki/concepts/Cross-account-Terraform-Modules.md b/wiki/concepts/Cross-account-Terraform-Modules.md
new file mode 100644
index 00000000..0607f05a
--- /dev/null
+++ b/wiki/concepts/Cross-account-Terraform-Modules.md
@@ -0,0 +1,61 @@
+---
+title: "Cross-account Terraform Modules"
+type: concept
+tags: [Terraform, Cross-Account, Modules, IaC, AWS]
+sources: [ctp-topic-16-cross-account-terraform-modules]
+last_updated: 2026-04-14
+---
+
+## Overview
+
+Cross-account Terraform Modules 指的是在单个 Terraform 模块中通过配置多个 AWS Provider，实现跨多个 AWS 账号同时创建或管理资源的能力。
+
+## Problem Statement
+
+在复杂的云架构中（如 AWS Landing Zone），经常需要在一个模块内跨多个账号创建资源。例如：
+- 在 **InfoBlocks 账号** 配置 DNS 记录
+- 在 **Workload 账号** 部署应用服务
+
+原有的 Gruntwork 流水线主要针对单账号设计，直接赋予账号间互访权限存在巨大安全风险——某一账号被攻破可能波及全局。
+
+## Solution Architecture
+
+基于 **Shared Account（共享账号）** 的中心化部署方案：
+
+1. **Jenkins 托管于 Shared Account**，当检测到模块目录中存在 `cross-account.json` 标记文件时，触发 ECS Deploy Runner
+2. **ECS Deploy Runner**（运行在 ECS 上的 Docker 容器）被授予特殊权限，通过 Assume Role 访问目标账号：
+ - `TF state bucket accessor`：读取目标账号 S3 桶中的 Terraform 状态文件
+ - `cross-account ECS deploy runner role`：在目标账号内执行资源部署
+3. 通过根目录 `terragrunt.hcl` 配置角色切换逻辑
+
+## Three Design Goals
+
+| Goal | Mechanism | Benefit |
+|------|-----------|---------|
+| **安全性** | 无 Workload 账号间直接信任，权限集中于 Shared Account | 控制 Blast Radius |
+| **自动化** | Jenkins 自动识别模块类型并选择正确部署路径 | 无人工干预 |
+| **可复用性** | 模块代码不硬编码特定账号的角色 | 灵活适配多环境 |
+
+## Key Files
+
+- `cross-account.json`：约定俗成的标记文件，放置于模块目录中，告知 Jenkins 调用跨账号部署逻辑
+- `terragrunt.hcl`（Root）：全局 Terragrunt 配置文件，定义远程状态存储和角色切换逻辑
+
+## Relationships
+
+- [[ECS Deploy Runner]] — 执行单元，运行 Docker 容器执行 plan/apply
+- [[Shared Account]] — 信任源，托管 Jenkins 和公共服务
+- [[Terraform]] — 底层 IaC 工具
+- [[Gruntwork]] — 参考架构来源
+- [[AWS-Landing-Zone]] — 多账号架构框架
+
+## Related Concepts
+
+- [[Infrastructure-as-Code]] — 上层方法论
+- [[GitOps]] — 部署编排模式
+- [[Assume Role]] — 跨账号身份切换机制（AWS IAM）
+
+## Notes
+
+- 本方案与单账号 Gruntwork 流水线为**演进关系**而非冲突
+- 本方案与 Atlantis 跨账号 IAM Role 机制**类似**，但执行载体不同（ECS 容器 vs EC2）
diff --git a/wiki/concepts/DRY-Principle.md b/wiki/concepts/DRY-Principle.md
new file mode 100644
index 00000000..38b01c38
--- /dev/null
+++ b/wiki/concepts/DRY-Principle.md
@@ -0,0 +1,68 @@
+---
+title: "DRY Principle"
+type: concept
+tags:
+ - software-engineering
+ - iac
+ - best-practices
+sources: [ctp-topic-48-terraform-vs-terragrunt]
+last_updated: 2026-04-26
+---
+
+# DRY Principle
+
+## Definition
+
+DRY（Don't Repeat Yourself，勿重复自己）是一项软件工程原则，主张：**系统中的每一条知识必须有一个单一的、明确的、权威的表示**。DRY 的核心目标是减少重复代码和配置，提高系统的可维护性、可扩展性和可测试性。
+
+## Core Idea
+
+> "Every piece of knowledge must have a single, unambiguous, authoritative representation within a system."
+
+DRY 不是简单的"不复制粘贴"，而是更深层的原则：**避免重复的知识**。这包括：
+- 代码逻辑
+- 配置文件
+- 文档注释
+- 数据结构
+
+## DRY in IaC
+
+在基础设施即代码（IaC）领域，DRY 尤为重要，因为基础设施配置往往需要在多个环境（dev/staging/prod）中复用：
+
+| 实践 | 说明 |
+|------|------|
+| **Terragrunt** | 封装 Terraform，通过 `remote_state` 和 `include` 块统一管理跨环境的 provider 和状态配置 |
+| **Terraform Modules** | 将可复用的基础设施组件抽象为模块，避免在每个环境中重复定义 |
+| **Service Catalog** | 企业级模块目录，支持三级复用（单账户→产品团队→跨团队） |
+| **Hierarchical Configuration** | 层级配置继承，父级定义通用配置，子级覆盖特定值 |
+
+**来源**: [[ctp-topic-48-terraform-vs-terragrunt]], [[ctp-topic-3-deploy-and-maintain-infrastructure]]
+
+## DRY vs WET
+
+| 原则 | 全称 | 结果 |
+|------|------|------|
+| **DRY** | Don't Repeat Yourself | 一次定义，多次引用 |
+| **WET** | Write Everything Twice | 多次重复，维护成本高 |
+
+WET 的典型反模式：
+- 复制粘贴配置到每个环境
+- 硬编码值而非使用变量
+- 注释与代码不同步
+
+## When NOT to Apply DRY
+
+DRY 不是绝对的，在以下情况下适度重复是可接受的：
+- **性能优化**：内联代码可能比函数调用更快
+- **可读性**：过度抽象可能导致代码难以理解
+- **解耦**：强制的 DRY 可能增加组件间的耦合
+
+## Related Concepts
+
+- [[Infrastructure-as-Code]] — DRY 原则的重要应用领域
+- [[Terraform]] — Terragrunt 的底层引擎
+- [[Terragrunt]] — DRY 原则在 Terraform 生态中的具体实现
+
+## Related Sources
+
+- [[ctp-topic-48-terraform-vs-terragrunt]]
diff --git a/wiki/concepts/Event-Driven-Architecture.md b/wiki/concepts/Event-Driven-Architecture.md
new file mode 100644
index 00000000..5f3c1266
--- /dev/null
+++ b/wiki/concepts/Event-Driven-Architecture.md
@@ -0,0 +1,108 @@
+---
+title: "Event-Driven Architecture"
+type: concept
+tags:
+ - Architecture
+ - Event-Driven
+ - Serverless
+ - AWS
+sources:
+ - public-cloud-learning-sessions-opentext-serverless-computing-20240903-160139-mee
+ - public-cloud-learning-sessions-opentext-event-driven-architecture-part-1-2024091
+ - public-cloud-learning-sessions-opentext-event-driven-architecture-part-2-2024091
+last_updated: 2026-05-05
+---
+
+## Definition
+
+Event-Driven Architecture（事件驱动架构）是一种软件设计范式，在该模式下，系统组件通过产生和消费事件（Event）进行异步通信，而非通过直接的函数调用或请求-响应模式。事件是系统中发生的重要动作或状态变化的声明式通知，事件消费者无需知道事件产生者的存在。
+
+## Core Principles
+
+| 原则 | 描述 |
+|------|------|
+| 异步通信 | 生产者和消费者解耦，无需同步等待响应 |
+| 事件声明 | 事件代表"发生了什么"，而非"该做什么" |
+| 松耦合 | 生产者和消费者之间无直接依赖 |
+| 可扩展 | 新增消费者无需修改生产者代码 |
+
+## Event Anatomy
+
+典型事件包含：
+
+```json
+{
+ "event_id": "uuid",
+ "event_type": "ORDER_CREATED",
+ "source": "order-service",
+ "timestamp": "2026-04-14T10:00:00Z",
+ "data": { /* 业务相关数据 */ }
+}
+```
+
+## AWS Event-Driven Stack
+
+| 组件 | 角色 | 说明 |
+|------|------|------|
+| [[Amazon-EventBridge]] | 事件总线 | 接收、过滤、路由事件到目标 |
+| [[AWS-Lambda]] | 事件消费者 | 响应事件执行处理逻辑 |
+| [[Amazon-SNS]] | 事件发布/订阅 | 一对多广播消息 |
+| [[Amazon-SQS]] | 事件队列 | 可靠的事件持久化和顺序处理 |
+| [[Amazon-DynamoDB]] | 事件源 | DynamoDB Streams 触发 Lambda |
+| [[Amazon-S3]] | 事件源 | S3 事件通知触发 Lambda |
+
+## Serverless 中的事件驱动
+
+[[AWS-Lambda]] 是事件驱动架构的核心执行单元：
+
+- **事件即触发器**：Lambda 函数不主动运行，由事件触发
+- **事件源映射**：Lambda 轮询 Kinesis、DynamoDB Stream、SQS 获取事件
+- **状态变化即事件**：S3 对象上传、API Gateway 请求、DynamoDB 写入等均为事件
+
+## Event Patterns
+## EDA 三组件与事件代理类型
+
+| 组件 | 角色 | 说明 |
+|------|------|------|
+| 事件生产者（Producer） | 产生事件 | 服务检测到状态变化时发布事件 |
+| 事件消费者（Consumer） | 消费事件 | 订阅并处理事件，执行对应业务逻辑 |
+| 事件代理（Broker） | 路由/存储 | 分事件路由器和事件存储两类 |
+
+**事件路由器（Event Routers）**——按规则过滤事件并路由到正确消费者：
+- [[Amazon-EventBridge]]：更丰富，支持 Schema 注册、跨服务触发
+- [[Amazon-SNS]]：一对多广播（Fan-out）
+
+**事件存储（Event Stores）**——流式持久化事件，消费者自行过滤：
+- [[Amazon-SQS]]：标准队列（乱序/高性能）/ FIFO 队列（有序/Exactly-Once）
+- [[Kinesis-Data-Streams]]：有序事件流，支持重放
+
+## 编排模式：Choreography vs Orchestration
+
+| 模式 | 特点 | 适用场景 |
+|------|------|---------|
+| Choreography（编排） | 各微服务自主通信，无中央协调者 | 简单、独立的跨服务交互 |
+| Orchestration（编排） | 中央协调者（如 [[AWS-Step-Functions]]）控制工作流步骤 | 复杂业务流程、需要事务保障 |
+
+## 生产级最佳实践
+
+1. **幂等性（Idempotency）**：同一操作执行一次或多次产生相同结果。[[AWS-Lambda]] 异步调用会自动重试，因此幂等性是处理重复消息的关键——尤其适用于订单、支付等场景。
+
+2. **事件排序**：
+ - **有序**：SQS FIFO 或 Kinesis Data Streams
+ - **乱序可接受**：标准 SQS 或 EventBridge（消费者自行处理乱序）
+
+3. **团队独立性**：采用去中心化所有权，平台团队提供基础设防（Cloud CoE），消费者团队自主按需消费事件。
+
+## Event Patterns
+1. **Pub/Sub**：SNS 主题广播，多消费者订阅同一事件类型
+2. **Event Streaming**：Kinesis/DynamoDB Stream 持久化事件流，支持重放
+3. **Fan-Out**：SNS 主题或 EventBridge 规则将事件分发到多个消费者
+4. **Competing Consumer**：同一消息同一时间只有一个消费者处理（SQS）
+5. **Dead-Letter Queue（DLQ）**：处理失败事件，防止消息丢失
+6. **Saga Pattern**：通过事件序列协调分布式事务
+7. **Event Sourcing**：完整记录所有状态变化事件作为唯一真相来源
+
+## Connections
+- [[Event-Driven-Architecture]] ← is_execution_model_of ← [[Serverless-Computing]]
+- [[Event-Driven-Architecture]] ← uses ← [[Amazon-EventBridge]]
+- [[Event-Driven-Architecture]] ← executed_by ← [[AWS-Lambda]]
diff --git a/wiki/concepts/Infrastructure-as-Code.md b/wiki/concepts/Infrastructure-as-Code.md
index 5e40bd27..ff5365db 100644
--- a/wiki/concepts/Infrastructure-as-Code.md
+++ b/wiki/concepts/Infrastructure-as-Code.md
@@ -1,37 +1,49 @@
---
title: "Infrastructure as Code"
type: concept
-tags: [DevOps, 自动化, 配置管理]
-sources: [ctp-topic-70-eks-deployment-using-iac, learning-sessions-ecs-deployment-using-iac-20230808-183322-meeting-recording, ctp-topic-16-cross-account-terraform-modules, ctp-topic-12-using-ses-smtp-service-terraform-module, learning-sessions-cloud-transformation-programme-deploying-rds-via-terraform]
-last_updated: 2026-04-24
+tags: [DevOps, AWS, Terraform, Automation]
+sources: [ctp-topic-3-deploy-and-maintain-infrastructure, ctp-topic-9-ci-cd-with-gruntwork, ctp-topic-48-terraform-vs-terragrunt, ctp-topic-32-using-atlantis-cicd-for-infrastructure-deployments, ctp-topic-33-an-introduction-to-gitops, ctp-topic-56-automated-infrastructure-testing, learning-sessions-ecs-deployment-using-iac-20230808-183322-meeting-recording]
+last_updated: 2026-05-05
---
# Infrastructure as Code
-## Overview
-Infrastructure as Code (IaC) 是一种通过代码定义和管理基础设施的方法，实现基础设施的标准化、可审计和可重复部署。
+## Definition
+基础设施即代码（Infrastructure as Code, IaC）是一种通过机器可读的定义文件（而非物理硬件配置或交互式配置工具）管理和配置计算基础设施的方法。
## Core Principles
-- **声明式配置**：定义期望的状态，而非执行的具体步骤
-- **版本控制**：所有基础设施配置纳入 Git 版本控制
-- **自动化部署**：通过 CI/CD 流水线自动化执行部署
-- **幂等性**：重复执行相同配置不产生副作用
+- **声明式配置**：描述期望的最终状态，而非执行的具体步骤
+- **版本控制**：所有基础设施定义文件存储在 Git 中
+- **幂等性**：多次执行产生相同结果
+- **可重复性**：同一模板可在不同环境快速部署
+- **自动化**：与 CI/CD 流水线集成
## Key Tools
-- **Terraform**：HashiCorp 的基础设施编排工具，支持多云
-- **AWS CloudFormation**：AWS 原生的 IaC 服务
-- **AWS Service Catalog**：AWS 的服务目录，封装标准化产品组合
-- **Pulumi**：使用编程语言（Python, TypeScript 等）定义基础设施
+- **Terraform**：HashiCorp 出品，云厂商无关的 IaC 工具，通过状态文件管理资源
+- **Terragrunt**：Terraform 轻量封装，贯彻 DRY 原则
+- **AWS CloudFormation**：AWS 原生 IaC 服务，JSON/YAML 模板
+- **Pulumi**：编程语言驱动的 IaC 平台
+- **Ansible**：配置管理和应用部署工具
-## Key Concepts
-- **HCL (HashiCorp Configuration Language)**：Terraform 的配置语言
-- **State Management**：Terraform 使用 state 文件追踪资源
-- **Modules**：可重用的基础设施组件
-- **Remote State**：远程状态存储，支持团队协作
+## Terraform Ecosystem
+- **Gruntwork**：预建 Terraform 模块库，生产级参考架构
+- **Atlantis**：Git 集成 Terraform 部署，PR 评论式协作
+- **Terratest**：Terraform 代码的 Go 测试框架
+- **tfsec**：Terraform 静态安全分析工具
+- **TFLint**：Terraform 代码规范检查
+
+## IaC in CTP Context
+CTP（Cloud Transformation Programme）使用 Terraform/Terragrunt 构建 AWS Landing Zone：
+- [[ctp-topic-3-deploy-and-maintain-infrastructure]]：Terragrunt HCL 文件与模块化管理
+- [[ctp-topic-9-ci-cd-with-gruntwork]]：Gruntwork CI/CD 流水线实践
+- [[ctp-topic-48-terraform-vs-terragrunt]]：Terraform 与 Terragrunt 对比选型
+- [[ctp-topic-32-using-atlantis-cicd-for-infrastructure-deployments]]：Atlantis 替代 Jenkins
+- [[ctp-topic-56-automated-infrastructure-testing]]：TerraTest 自动化测试
+- [[learning-sessions-ecs-deployment-using-iac-20230808-183322-meeting-recording]]：ECS IaC 部署实践
## Related Concepts
-- [[Terraform]]：最流行的 IaC 工具之一
-- [[AWS Service Catalog]]：AWS IaC 产品目录
-- [[GitOps]]：基于 Git 的运维方法论
-- [[CI/CD Pipeline]]：自动化部署流水线
-- [[DevOps Culture]]：IaC 是 DevOps 实践的核心组成
+- [[GitOps]]：Git 作为 IaC 的单一真相来源
+- [[CI/CD Pipeline]]：IaC 与 CI/CD 流水线的集成
+- [[Policy-as-Code]]：IaC 扩展至安全合规策略
+- [[Canary-Deployment]]：基于 IaC 的金丝雀部署策略
+- [[Atlantis]]：GitOps 驱动的 Terraform 协作工具
diff --git a/wiki/concepts/Serverless-Computing.md b/wiki/concepts/Serverless-Computing.md
index 8263daea..0ebe6ab5 100644
--- a/wiki/concepts/Serverless-Computing.md
+++ b/wiki/concepts/Serverless-Computing.md
@@ -1,76 +1,70 @@
---
title: "Serverless Computing"
type: concept
-tags: [Cloud, Serverless, Cloud Native, Edge Computing]
-date: 2026-04-26
+tags:
+ - Cloud
+ - Serverless
+ - AWS
+ - DevOps
+sources:
+ - public-cloud-learning-sessions-opentext-serverless-computing-20240903-160139-mee
+last_updated: 2026-04-14
---
-# Serverless Computing (无服务器计算)
-
## Definition
-**Serverless Computing** is a cloud execution model where the cloud provider dynamically manages the allocation and provisioning of servers. Developers can build and deploy applications without worrying about infrastructure management.
-## Key Characteristics
-- **No server management**: Cloud provider handles infrastructure
-- **Automatic scaling**: Resources scale based on demand
-- **Pay-per-use**: Pay only for execution time
-- **Event-driven**: Functions respond to events/triggers
+Serverless Computing（无服务器计算）是一种云原生执行模型，在该模式下，云厂商承担底层基础设施的全部运维责任（负载均衡、自动扩展、安全补丁、容量管理），开发者只需专注编写业务逻辑代码。Serverless 并非"无服务器"，而是将服务器管理抽象给云厂商。
-## Key Platforms
+## Core Characteristics
-| Provider | Service |
-|----------|---------|
-| AWS | Lambda |
-| Azure | Azure Functions |
-| GCP | Cloud Functions |
+| 特性 | 描述 |
+|------|------|
+| 无运维 | 云厂商管理服务器操作系统、运行时和安全补丁 |
+| 事件驱动 | 函数由事件触发，事件即资源状态的任何变化 |
+| 按需付费 | 仅在函数执行时计费（按调用次数和执行时长） |
+| 自动扩展 | 云厂商根据请求量自动水平扩展，无需人工干预 |
+| 内置安全 | 云厂商提供基础安全能力（网络隔离、IAM 权限控制） |
-## Benefits
+## Business Value
-### 1. Cost Efficiency
-- Eliminates unnecessary resource consumption
-- No idle capacity costs
-- Pay only for actual execution time
+企业采用 Serverless 的核心驱动因素：
+- **更快上市时间**（Faster Time to Market）：开发团队专注业务逻辑，无需管理基础设施
+- **业务聚焦**（Business Focus）：将非核心运维任务外包给云厂商
+- **更低 TCO**（Total Cost of Ownership）：按需付费，空闲时零成本
+- **弹性扩展**（Elastic Scalability）：从零到百万并发自动应对
+- **内置安全**（Built-in Security）：云厂商持续更新安全补丁
-### 2. Scalability
-- Automatic scaling from zero to thousands of instances
-- Handles traffic spikes without provisioning
-- Global distribution ready
+## AWS Serverless Ecosystem
-### 3. Developer Productivity
-- Focus on business logic, not infrastructure
-- Faster deployment cycles
-- Reduced operational overhead
+AWS 提供完整的 Serverless 服务矩阵：
-## Use Cases
+| 服务 | 作用 | 关系 |
+|------|------|------|
+| [[AWS-Lambda]] | 无服务器计算核心 | 函数执行层 |
+| [[Amazon-API-Gateway]] | API 创建、发布、安全 | API 暴露层 |
+| [[AWS-Step-Functions]] | 工作流编排 | 流程编排层 |
+| [[Amazon-EventBridge]] | 事件总线 | 事件路由层 |
+| [[AWS-Fargate]] | 无服务器容器 | 容器层的 Serverless |
+| [[Amazon-DynamoDB]] | 无服务器数据库 | 数据持久层 |
+| [[SAM-Serverless-Application-Model]] | 本地开发和部署工具 | 开发工具层 |
-### Event-Driven Automation
-- Real-time file processing
-- Automated backups
-- Scheduled tasks and cron jobs
+## Shared Responsibility Model
-### API Backends
-- Microservices architecture
-- Real-time data processing
-- IoT data ingestion
+在 Serverless 环境中，AWS 与客户共担运维责任：
-### AI/ML Inference
-- On-demand model inference
-- Image and video processing
-- Natural language processing
+- **AWS 负责**：基础设施、服务器硬件、网络、运行时环境、安全补丁、负载均衡、自动扩展
+- **客户负责**：业务代码、依赖管理、权限配置（IAM）、应用程序级别的安全
-## Relationship to Green Computing
-- Serverless computing contributes to [[Green Computing]] by:
- - Eliminating idle resource consumption
- - Optimizing energy efficiency through shared infrastructure
- - Reducing data center carbon footprint
+## Event-Driven Architecture Connection
+
+Serverless 天然契合 [[Event-Driven-Architecture]] 模式：
+
+1. **事件源**（Event Source）：S3、API Gateway、EventBridge、DynamoDB Stream 等
+2. **事件路由器**（Event Router）：EventBridge、SNS 等筛选和路由事件
+3. **Lambda 函数**（Function）：消费事件，执行业务逻辑
+4. **下游服务**（Downstream）：DynamoDB、SQS、SNS 等处理结果
## Related Concepts
-- [[Cloud-Native]]
-- [[Green Computing]]
-- [[Event-Driven-Architecture]]
-- [[Edge-Computing]]
-
-## Related Entities
-- [[AWS Lambda]]
-- [[Azure Functions]]
-- [[Google Cloud Functions]]
+- [[Event-Driven-Architecture]] — Serverless 的天然执行模型
+- [[Lambda-Permissions-Model]] — Serverless 函数的安全权限模型
+- [[Cloud-Transformation-Programme]] — Serverless 是云转型的关键技术路径之一
diff --git a/wiki/entities/AWS-Lambda.md b/wiki/entities/AWS-Lambda.md
new file mode 100644
index 00000000..8abf75a3
--- /dev/null
+++ b/wiki/entities/AWS-Lambda.md
@@ -0,0 +1,78 @@
+---
+title: "AWS Lambda"
+type: entity
+tags:
+ - AWS
+ - Serverless
+ - Compute
+ - Lambda
+sources:
+ - public-cloud-learning-sessions-opentext-serverless-computing-20240903-160139-mee
+last_updated: 2026-04-14
+---
+
+## Aliases
+- Lambda
+- AWS Lambda
+
+## Definition
+
+AWS Lambda 是 AWS 的无服务器（Serverless）计算服务——开发者只需编写业务逻辑函数（Handler），AWS 负责所有底层运维：负载均衡、自动扩展、安全补丁和容量管理。Lambda 函数由事件（event）触发，事件即云资源状态的任何变化。
+
+## Core Properties
+
+| 属性 | 值 |
+|------|-----|
+| 触发模式 | 同步调用、异步调用、事件源映射 |
+| 权限模型 | 执行角色（Execution Role）+ 资源策略（Resource-Based Policy） |
+| 代码管理 | 版本（Version）、别名（Alias）、Layers（共享公共依赖） |
+| 架构支持 | x86 和 ARM64（ARM64 提供更优性价比） |
+| 监控 | CloudWatch 指标（请求数、错误数、延迟、节流） |
+| 调试工具 | Amazon Q（集成 AI 辅助调试） |
+| 性能调优 | Lambda Power Tuning（比较不同配置的性能和成本） |
+
+## Lambda Handler 模式
+
+Lambda 函数接收三个核心参数：
+
+1. **Handler** — 入口函数，事件触发时执行
+2. **Event Object** — 触发事件的数据结构（API Gateway 请求、S3 对象变更等）
+3. **Context Object** — 运行时信息（超时设置、内存限制、日志句柄等）
+
+## Invocation Patterns
+
+- **同步调用（Synchronous）**：调用方等待响应，如 API Gateway → Lambda
+- **异步调用（Asynchronous）**：Lambda 自动处理重试（最多 2 次），如 S3 事件 → Lambda
+- **事件源映射（Event Source Mapping）**：Lambda 轮询流式服务（Kinesis、DynamoDB Stream、SQS）批量处理记录
+
+## Permissions Model
+
+Lambda 权限模型基于 IAM 的最小权限原则：
+
+| 权限类型 | 作用对象 | 说明 |
+|---------|---------|------|
+| Execution Role | Lambda 函数 | 定义函数能调用哪些 AWS 资源和服务 |
+| Resource-Based Policy | 其他 AWS 账号/服务 | 定义谁能/什么能触发该 Lambda 函数 |
+
+## Lambda Layers
+
+Lambda Layers 允许跨多个 Lambda 函数共享公共代码和依赖：
+- 运行时环境（如 Python boto3 库）
+- 自定义运行时
+- 配置和脚本
+
+Layers 避免了每个函数重复打包相同依赖，减少部署包大小和更新成本。
+
+## Connections
+- [[Serverless-Computing]] ← is_core_service_of ← [[AWS-Lambda]]
+- [[AWS-Lambda]] ← triggered_by ← [[Amazon-EventBridge]]
+- [[AWS-Lambda]] ← exposed_via ← [[Amazon-API-Gateway]]
+- [[AWS-Lambda]] ← orchestrated_by ← [[AWS-Step-Functions]]
+- [[AWS-Lambda]] ← monitored_by ← [[CloudWatch]]
+- [[SAM-Serverless-Application-Model]] ← deploys ← [[AWS-Lambda]]
+
+## Related Entities
+- [[Amazon-API-Gateway]] — Lambda 的 API 暴露层
+- [[AWS-Step-Functions]] — Lambda 的工作流编排层
+- [[Amazon-EventBridge]] — Lambda 的事件驱动触发源
+- [[CloudWatch]] — Lambda 的监控和日志层
diff --git a/wiki/entities/AWS-Step-Functions.md b/wiki/entities/AWS-Step-Functions.md
new file mode 100644
index 00000000..6d53d09d
--- /dev/null
+++ b/wiki/entities/AWS-Step-Functions.md
@@ -0,0 +1,56 @@
+---
+title: "AWS Step Functions"
+type: entity
+tags:
+ - AWS
+ - Serverless
+ - Workflow
+ - Orchestration
+sources:
+ - public-cloud-learning-sessions-opentext-serverless-computing-20240903-160139-mee
+last_updated: 2026-04-14
+---
+
+## Aliases
+- Step Functions
+- AWS Step Functions
+- Amazon Step Functions
+
+## Definition
+
+AWS Step Functions 是 AWS 的无服务器工作流编排服务，基于状态机（State Machine）协调多个 Lambda 函数和 AWS 服务的执行顺序和错误处理逻辑，使开发者无需编写复杂的编排代码即可构建可靠的多步骤业务流程。
+
+## Core Properties
+
+| 属性 | 值 |
+|------|-----|
+| 核心抽象 | 状态机（Standard 和 Express 两种） |
+| Standard 工作流 | 长时运行，最长 1 年，支持精确执行历史 |
+| Express 工作流 | 高频场景，最长 5 分钟，支持极高吞吐量 |
+| 状态类型 | Task、Choice、Wait、Pass、Parallel、Map、End、Throw |
+| 错误处理 | 内置 Retry、Catch 和 Error 字段 |
+| 可视化 | 自动生成工作流图形，直观展示执行路径 |
+
+## Workflow Flavors
+
+| 类型 | 适用场景 | 执行时长 | 计费模式 |
+|------|---------|---------|---------|
+| Standard | 长时业务流程、审批流、数据处理管道 | 最长 1 年 | 按状态转换计费 |
+| Express | 高频事件处理、IoT 数据流水线、实时流处理 | 最长 5 分钟 | 按执行次数+GB/s计费 |
+
+## State Types
+
+Step Functions 提供丰富的状态类型构建复杂工作流：
+
+- **Task**：执行单个原子工作单元（如调用 Lambda、DynamoDB 操作）
+- **Choice**：条件分支，基于数据动态路由执行路径
+- **Wait**：等待指定时间（用于轮询、重试间隔）
+- **Pass**：直接传递输入到输出（数据转换）
+- **Parallel**：并行执行多个分支，汇合结果
+- **Map**：迭代处理数组中的每个元素
+- **End/Try-Throw**：终止和错误处理
+
+## Connections
+- [[AWS-Step-Functions]] ← orchestrates ← [[AWS-Lambda]]
+- [[AWS-Step-Functions]] ← is_a ← [[Serverless-Computing]]
+- [[AWS-Step-Functions]] ← triggers ← [[Amazon-EventBridge]]
diff --git a/wiki/entities/Amazon-API-Gateway.md b/wiki/entities/Amazon-API-Gateway.md
new file mode 100644
index 00000000..6a58a056
--- /dev/null
+++ b/wiki/entities/Amazon-API-Gateway.md
@@ -0,0 +1,60 @@
+---
+title: "Amazon API Gateway"
+type: entity
+tags:
+ - AWS
+ - Serverless
+ - API
+ - Networking
+sources:
+ - public-cloud-learning-sessions-opentext-serverless-computing-20240903-160139-mee
+last_updated: 2026-04-14
+---
+
+## Aliases
+- API Gateway
+- Amazon API Gateway
+- AWS API Gateway
+
+## Definition
+
+Amazon API Gateway 是 AWS 的全托管 API 管理服务，用于创建、发布、维护和监控安全的企业级 REST、HTTP 和 WebSocket API。API Gateway 作为 Lambda 函数和其他后端服务的统一入口，提供流量管理、授权和访问控制、监控等企业级能力。
+
+## Core Properties
+
+| 属性 | 值 |
+|------|-----|
+| API 类型 | REST API、HTTP API、WebSocket API |
+| 部署选项 | Edge-Optimized、Regional、Private |
+| 认证方式 | IAM 角色、Lambda Authorizer、Cognito、API Key |
+| 协议 | HTTPS（TLS 终止由 AWS 管理） |
+| 限流 | 按账户/按 API/按客户多级限流 |
+| 缓存 | 可选 API 缓存，提升响应速度 |
+| 监控 | CloudWatch 集成，提供延迟、错误率等指标 |
+
+## Deployment Options
+
+| 选项 | 说明 | 适用场景 |
+|------|------|---------|
+| Edge-Optimized | 通过 CloudFront CDN 全球分发，低延迟 | 面向全球用户的公共 API |
+| Regional | 部署在单一区域，自带高可用 | 面向同区域用户、VPC 内的 API |
+| Private | 仅可通过 VPC 内部端点访问 | 企业内部 API、微服务间通信 |
+
+## Typical Architecture
+
+```
+客户端 → API Gateway → Lambda Function → DynamoDB/SQS/etc.
+```
+
+API Gateway 负责：
+1. TLS 终止（安全）
+2. 请求验证（格式、参数）
+3. 限流和配额管理
+4. 授权和身份验证
+5. 请求路由到后端 Lambda
+6. 响应转换和格式统一
+
+## Connections
+- [[Amazon-API-Gateway]] ← exposes ← [[AWS-Lambda]]
+- [[Amazon-API-Gateway]] ← provides ← [[Serverless-Computing]]
+- [[Amazon-API-Gateway]] ← monitored_by ← [[CloudWatch]]
diff --git a/wiki/entities/Atlantis.md b/wiki/entities/Atlantis.md
new file mode 100644
index 00000000..1bac86dc
--- /dev/null
+++ b/wiki/entities/Atlantis.md
@@ -0,0 +1,95 @@
+---
+title: "Atlantis"
+type: entity
+tags:
+ - devops
+ - iac
+ - terraform
+ - gitops
+ - cicd
+created: 2026-04-26
+---
+
+# Atlantis
+
+## Definition
+
+Atlantis 是一个开源的**Terraform CI/CD 工具**，通过与 GitHub/GitLab 深度集成，将 Terraform 的 plan 和 apply 操作转移到 Pull Request（PR）评论层面，实现基础设施即代码的协作式自动化部署。
+
+## Core Model: PR-Driven IaC
+
+Atlantis 的核心理念：**每个 Pull Request 都是一次 Terraform 操作**。
+
+```
+Developer Atlantis AWS Accounts
+ │ │ │
+ │ 1. Open PR │ │
+ │───────────────────────>│ │
+ │ │ 2. !atlantis plan │
+ │ │───────────────────────>│
+ │ │<───────────────────────│ 3. terraform plan
+ │ 4. Post plan result │ │
+ │<───────────────────────│ │
+ │ 5. Review & Approve │ │
+ │───────────────────────>│ │
+ │ │ 6. !atlantis apply │
+ │ │───────────────────────>│
+ │ │<───────────────────────│ 7. terraform apply
+ │ 8. Merge PR │ │
+ │───────────────────────>│ │
+```
+
+**来源**: [[ctp-topic-32-using-atlantis-cicd-for-infrastructure-deployments]]
+
+## Key Features
+
+| 特性 | 说明 |
+|------|------|
+| **PR 评论触发** | 无需独立 CI 账号，开发者在 PR 上评论即可 |
+| **并行 plan/apply** | 多模块并发执行，提升部署效率 |
+| **锁定机制** | 防止多 PR 同时操作同一模块产生冲突 |
+| **跨账户访问** | 通过 IAM 角色实现多 AWS 账户部署 |
+| **零额外基础设施** | 只需一台 EC2 共享账户实例 |
+
+**来源**: [[ctp-topic-32-using-atlantis-cicd-for-infrastructure-deployments]]
+
+## Comparison: Atlantis vs Jenkins
+
+| 维度 | Atlantis | Jenkins |
+|------|----------|---------|
+| 触发方式 | PR 评论 | SCM 轮询/定时 |
+| 初始化速度 | 快速（按需） | 慢（Jenkins 预配置） |
+| 代码克隆 | 单次 | 多次 |
+| 测试执行 | 并行 | 顺序 |
+| 架构复杂度 | 简单 | 复杂（持续叠加功能） |
+| Terraform 专用 | ✅ 是 | ❌ 通用（需配置） |
+| PR 协作 | ✅ 原生 | ❌ 无 |
+
+**来源**: [[ctp-topic-32-using-atlantis-cicd-for-infrastructure-deployments]]
+
+## Micro Focus Usage
+
+Micro Focus 在 Labs Landing Zone 中使用 Atlantis 替代 Jenkins 进行 Terraform IaC 部署：
+- 每个 Landing Zone 共享账户部署单台 EC2 实例
+- GitHub Enterprise Webhook 接收 PR 事件
+- 服务账号负责评论/合并/关闭 PR
+- Atlantis 在 merge 前即应用变更
+
+**局限性**: Atlantis 当前不支持 EKS 部署，需通过 Jenkins + Terragrunt 模块替代。
+
+**来源**: [[ctp-topic-32-using-atlantis-cicd-for-infrastructure-deployments]], [[ctp-topic-39-implementing-eks-in-the-aws-lab-landing-zone]]
+
+## Related Entities
+
+- [[Terraform]] — Atlantis 操作的核心 IaC 工具
+- [[Gruntwork]] — Terragrunt 的开发者（Atlantis 生态伙伴）
+
+## Related Concepts
+
+- [[GitOps]] — Atlantis 是 GitOps 在 Terraform 领域的实现工具
+- [[CI/CD Pipeline]] — Atlantis 提供 CI/CD 能力
+
+## Related Sources
+
+- [[ctp-topic-32-using-atlantis-cicd-for-infrastructure-deployments]]
+- [[ctp-topic-39-implementing-eks-in-the-aws-lab-landing-zone]]
diff --git a/wiki/entities/Gruntwork.md b/wiki/entities/Gruntwork.md
index 0529e453..b69025e9 100644
--- a/wiki/entities/Gruntwork.md
+++ b/wiki/entities/Gruntwork.md
@@ -1,30 +1,32 @@
---
title: "Gruntwork"
type: entity
-sources: [ctp-topic-17-active-directory-services-in-gruntwork-aws-lzs]
-last_updated: 2026-04-14
+tags: [AWS, IaC, DevOps, Terraform]
+sources: [ctp-topic-9-ci-cd-with-gruntwork, ctp-topic-48-terraform-vs-terragrunt, learning-sessions-ecs-deployment-using-iac-20230808-183322-meeting-recording]
+last_updated: 2026-05-05
---
+# Gruntwork
+
## Overview
-Gruntwork 是 Micro Focus Cloud Transformation Programme (CTP) 中采用的 AWS Landing Zones 基础设施框架提供方。Gruntwork Landing Zones 提供预配置的、基于最佳实践的 AWS 基础架构模板，帮助企业快速构建符合安全和合规要求的 AWS 多账户架构。
+Gruntwork 是一家专注于 AWS 基础设施即代码（IaC）的公司，提供预构建、可定制的 Terraform 模块库，帮助团队快速构建生产级云基础设施。
-## Aliases
-- Gruntwork AWS Landing Zones
-- Gruntwork LZ
+## Products
+- **Gruntwork Landing Zone Architecture**：基于 Terraform/Terragrunt 的 AWS Landing Zone 参考架构，涵盖账户结构、网络、安全、运维等基础设施层
+- **Gruntwork Infrastructure Live**：生产级 Terraform 模块库，支持多账户、多区域部署
+- **Pipelines**：Gruntwork 推荐的 CI/CD 流水线方案，集成 GitHub Actions/Jenkins
-## Key Capabilities
-- **多环境支持**：区分 R&D Labs 和 SAS（Staging/Production）两种环境类型，分别对应不同的 AD 域名架构
-- **预制 AMI**：SRE 团队维护内置域加入脚本的标准化机器镜像
-- **IaC 集成**：与 Terraform/TerraGrunt 深度集成，支持 `user_data` 触发自动化域加入流程
-- **AD 集成**：提供标准化的 Active Directory 服务集成方案，包括 DNS 管理和安全动态更新
+## Key Modules
+- **ECS 模块**：Docker 容器部署模块，CTP/SRE 团队在此基础上构建了自己的 ECS 模块（实现 Listener 集中管理）
+- **EKS 模块**：Kubernetes 集群部署模块
+- **Landing Zone 模块**：AWS 组织、账户、OU 架构
-## Related Entities
-- [[SRE Team]]：构建和维护 Gruntwork LZ 中预制 AMI 的团队
-- [[Gruntwork AWS Landing Zones Overview]]：Gruntwork LZ 的整体架构概述
-- [[ctp-topic-17-active-directory-services-in-gruntwork-aws-lzs]]：AD 服务集成的核心参考文档
+## Gruntwork in CTP Context
+- [[ctp-topic-9-ci-cd-with-gruntwork]]：CTP Topic 9 深入 Gruntwork CI/CD 实践
+- [[ctp-topic-48-terraform-vs-terragrunt]]：Terraform 与 Terragrunt 对比，Gruntwork 作为辅助工具推荐
+- [[learning-sessions-ecs-deployment-using-iac-20230808-183322-meeting-recording]]：CTP 团队在 Gruntwork 仓库基础上开发 ECS 模块
-## References
-- [[ctp-topic-17-active-directory-services-in-gruntwork-aws-lzs]]
-- [[ctp-topic-14-octane-hub-on-aws-real-life-experience-moving-production-services-i]]
-- [[ctp-topic-9-ci-cd-with-gruntwork]]
-- [[ctp-topic-1-gruntwork-landing-zone-architecture]]
+## Connections
+- [[HashiCorp]] ← provider_of ← [[Terraform]] ← uses ← [[Gruntwork]]
+- [[Atlantis]] ← alternative_to ← [[Gruntwork-Pipelines]]
+- [[Gruntwork]] ← builds_on ← [[Infrastructure-as-Code]]
diff --git a/wiki/entities/HashiCorp.md b/wiki/entities/HashiCorp.md
new file mode 100644
index 00000000..80ac7481
--- /dev/null
+++ b/wiki/entities/HashiCorp.md
@@ -0,0 +1,59 @@
+---
+title: "HashiCorp"
+type: entity
+tags:
+ - devops
+ - iac
+ - infrastructure
+ - tools
+created: 2026-04-26
+---
+
+# HashiCorp
+
+## Definition
+
+HashiCorp 是全球领先的**云基础设施自动化**软件公司，总部位于旧金山，创立于 2012 年。HashiCorp 提供一套完整的基础设施生命周期管理工具，覆盖配置管理、机密管理、服务网格和网络自动化等领域。
+
+## Core Products
+
+| 产品 | 用途 | 类别 |
+|------|------|------|
+| **Terraform** | 云厂商无关的基础设施即代码 | IaC |
+| **Vault** | 机密管理与加密即服务 | 安全 |
+| **Nomad** | 容器和工作负载调度器 | 编排 |
+| **Consul** | 服务网格与服务发现 | 网络 |
+| **Packer** | 机器镜像构建自动化 | 镜像 |
+| **Vagrant** | 开发环境管理 | 开发环境 |
+
+## Terraform
+
+HashiCorp 最知名的产品。Terraform 是用 Golang 编写的云无关 IaC 工具，通过声明式 HCL（HashiCorp Configuration Language）管理跨多云和混合云环境的基础设施资源。
+
+**关键特性：**
+- 云厂商无关（AWS/Azure/GCP/On-prem）
+- `terraform plan` 预览变更
+- 状态文件管理实际资源与期望状态的绑定
+- 丰富的 Provider 生态系统和 Module 市场
+
+**来源**: [[ctp-topic-48-terraform-vs-terragrunt]]
+
+## Business Model
+
+- **开源**：所有产品的开源版本
+- **Enterprise**：企业级功能（SSO、RBAC、审计日志、Sentinel 策略）
+- **HCP（HashiCorp Cloud Platform）**：SaaS 托管版本
+
+## Related Entities
+
+- [[Terraform]] — HashiCorp 出品的核心 IaC 产品
+- [[Terragrunt]] — 第三方 Terraform 封装工具（贯彻 DRY 原则）
+
+## Related Concepts
+
+- [[Infrastructure-as-Code]] — HashiCorp 产品的核心方法论
+- [[Multi-Cloud Strategy]] — Terraform 云无关定位的战略价值
+
+## Related Sources
+
+- [[ctp-topic-48-terraform-vs-terragrunt]]
diff --git a/wiki/entities/SAM-Serverless-Application-Model.md b/wiki/entities/SAM-Serverless-Application-Model.md
new file mode 100644
index 00000000..dcaf92b4
--- /dev/null
+++ b/wiki/entities/SAM-Serverless-Application-Model.md
@@ -0,0 +1,86 @@
+---
+title: "SAM Serverless Application Model"
+type: entity
+tags:
+ - AWS
+ - Serverless
+ - IaC
+ - CloudFormation
+sources:
+ - public-cloud-learning-sessions-opentext-serverless-computing-20240903-160139-mee
+last_updated: 2026-04-14
+---
+
+## Aliases
+- SAM
+- AWS SAM
+- Serverless Application Model
+
+## Definition
+
+AWS SAM（Serverless Application Model）是 AWS 官方的开源 IaC 工具，基于 AWS CloudFormation 构建，专门简化无服务器应用（Lambda、API Gateway、Step Functions 等）的定义、部署和管理。SAM 提供简化的 YAML 语法，降低 CloudFormation 模板的复杂度，同时支持本地开发和测试。
+
+## Core Properties
+
+| 属性 | 值 |
+|------|-----|
+| 基础 | AWS CloudFormation |
+| 配置格式 | YAML（简化语法） |
+| CLI | AWS SAM CLI，支持本地调用和测试 |
+| 本地测试 | SAM Local — 本地启动 API Gateway + Lambda |
+| 部署 | `sam deploy`、`sam build`、`sam package` |
+| 应用发布 | AWS Serverless Application Repository（应用市场） |
+
+## SAM vs CloudFormation
+
+| 特性 | SAM | CloudFormation |
+|------|-----|----------------|
+| 语法 | 简化 YAML | JSON/YAML |
+| 资源类型 | 仅 Serverless 资源 | 全部 AWS 资源 |
+| 本地测试 | SAM Local | 不支持 |
+| 打包上传 | `sam package` | `aws cloudformation package` |
+| 模板继承 | `!Sub`、`!Ref` | 原生支持 |
+
+## Typical SAM Template
+
+```yaml
+AWSTemplateFormatVersion: '2010-09-09'
+Transform: AWS::Serverless-2016-10-31
+Resources:
+ MyFunction:
+ Type: AWS::Serverless::Function
+ Properties:
+ Handler: app.handler
+ Runtime: python3.12
+ Events:
+ ApiEvent:
+ Type: Api
+ Properties:
+ Path: /hello
+ Method: get
+ MyApi:
+ Type: AWS::Serverless::Api
+ Properties:
+ StageName: prod
+ DefinitionBody:
+ # OpenAPI spec
+```
+
+## SAM CLI 常用命令
+
+| 命令 | 作用 |
+|------|------|
+| `sam init` | 初始化新 SAM 项目 |
+| `sam build` | 构建应用（处理依赖、Layer） |
+| `sam local invoke` | 本地调用 Lambda 函数 |
+| `sam local start-api` | 本地启动完整 API（API Gateway + Lambda） |
+| `sam deploy` | 交互式部署到 AWS |
+| `sam package` | 打包模板和代码到 S3 |
+| `sam validate` | 验证模板语法 |
+
+## Connections
+- [[SAM-Serverless-Application-Model]] ← builds_on ← [[CloudFormation]]
+- [[SAM-Serverless-Application-Model]] ← deploys ← [[AWS-Lambda]]
+- [[SAM-Serverless-Application-Model]] ← deploys ← [[Amazon-API-Gateway]]
+- [[SAM-Serverless-Application-Model]] ← deploys ← [[AWS-Step-Functions]]
+- [[SAM-Serverless-Application-Model]] ← is_tool_of ← [[Serverless-Computing]]
diff --git a/wiki/entities/Terraform.md b/wiki/entities/Terraform.md
index c479e854..fc55bc42 100644
--- a/wiki/entities/Terraform.md
+++ b/wiki/entities/Terraform.md
@@ -102,6 +102,36 @@ Agentic AI 在 Terraform 工作流中扮演审查者角色：
> acl = "private" # Block public access
> ```
+## State File Management
+
+Terraform 通过**状态文件 (state file)** 将声明式配置中定义的**期望状态**与云环境的**实际资源状态**进行绑定。关键特性：
+- **状态锁定**：防止并发执行导致状态不一致
+- **远程状态**：企业级场景需将状态文件存储在 S3（+ DynamoDB 锁）等远程后端，支持团队协作
+- **差异对比**：`terraform plan` 预览实际变更内容再执行，是 Terraform 的核心优势
+
+**来源**: [[ctp-topic-48-terraform-vs-terragrunt]]
+
+## Terragrunt Wrapper
+
+Terragrunt 是 Terraform 的轻量封装，继承所有 Terraform 命令（HCL 语法完全兼容）。两者关系：
+- `terragrunt plan` = `terraform plan`
+- Terragrunt 通过 `remote_state` 和 `include` 块实现跨环境配置的 DRY 管理
+
+**来源**: [[ctp-topic-48-terraform-vs-terragrunt]]
+
+## Ecosystem Tools
+
+| 工具 | 类型 | 用途 |
+|------|------|------|
+| [[Terragrunt]] | 封装 | 多环境 DRY 配置 |
+| [[Atlantis]] | CI/CD | Git PR 驱动的 plan/apply |
+| Terraform Enterprise | 平台 | 企业 CI + workspaces |
+| [[Gruntwork]] | 模块库 | 预建可复用 IaC 模块 |
+| Terratest | 测试 | IaC 集成测试（Golang） |
+| tfsec | 安全 | Terraform 静态安全分析 |
+
+**来源**: [[ctp-topic-48-terraform-vs-terragrunt]], [[ctp-topic-56-automated-infrastructure-testing]]
+
## Related Concepts
- [[Infrastructure-as-Code]] — Terraform 是 IaC 的实现工具
diff --git a/wiki/entities/Terragrunt.md b/wiki/entities/Terragrunt.md
new file mode 100644
index 00000000..6939b947
--- /dev/null
+++ b/wiki/entities/Terragrunt.md
@@ -0,0 +1,100 @@
+---
+title: "Terragrunt"
+type: entity
+tags:
+ - devops
+ - iac
+ - terraform
+ - automation
+created: 2026-04-26
+---
+
+# Terragrunt
+
+## Definition
+
+Terragrunt 是由 Gruntwork 开发的**Terraform 轻量封装工具**，核心目标是贯彻 DRY（Don't Repeat Yourself）原则，简化多环境、多账户 Terraform 配置的管理。
+
+## Core Value
+
+Terragrunt 对 Terraform 的核心改进在于**减少重复配置**：
+
+| 问题 | Terraform 方案 | Terragrunt 方案 |
+|------|---------------|----------------|
+| provider 块重复 | 每个环境独立声明 | `terragrunt.hcl` 统一管理 |
+| remote_state 块重复 | 多处硬编码 | 模板化复用 |
+| 模块引用方式 | 固定分支引用 | 版本锁定引用 |
+| 多环境同步 | 手动复制配置 | `include` 块继承 |
+
+**来源**: [[ctp-topic-48-terraform-vs-terragrunt]]
+
+## Compatibility
+
+Terragrunt **完全兼容** Terraform 的所有命令和 HCL 语法：
+- `terragrunt plan` → 底层调用 `terraform plan`
+- `terragrunt apply` → 底层调用 `terraform apply`
+- 所有 Terraform HCL 块和属性完全兼容
+
+这意味着 Terragrunt **不是** Terraform 的替代品，而是增强层。
+
+**来源**: [[ctp-topic-48-terraform-vs-terragrunt]]
+
+## Key Features
+
+### DRY Remote State
+通过 `remote_state` 块集中管理状态文件位置：
+```hcl
+remote_state {
+ backend = "s3"
+ config = {
+ bucket = "my-terraform-state"
+ key = "${path_relative_to_include()}/terraform.tfstate"
+ region = "eu-west-1"
+ encrypt = true
+ }
+}
+```
+
+### Provider Management
+跨环境统一 provider 配置，避免在每个模块中重复声明。
+
+### Include & Inheritance
+通过 `include` 块实现配置的继承与覆盖：
+```hcl
+include {
+ path = find_in_parent_folders("root.hcl")
+}
+```
+
+## Use Case: Micro Focus Labs Landing Zone
+
+Micro Focus Labs Landing Zone 使用 Terragrunt 管理多账户配置，所有资源通过 Terraform/Terragrunt 管理，Jenkins 流水线扫描 GitHub 仓库变更触发 plan/apply。
+
+**来源**: [[ctp-topic-3-deploy-and-maintain-infrastructure]], [[ctp-topic-25-labs-landing-zone-overview-itom-teams]]
+
+## Ecosystem Position
+
+```
+Terraform Ecosystem
+├── Terraform (HashiCorp) — 核心 IaC 引擎
+├── Terragrunt (Gruntwork) — DRY 封装层 ←
+├── Terraform Enterprise (HashiCorp) — 企业 CI 平台
+└── Gruntwork Library (Gruntwork) — 预建模块库
+```
+
+## Related Entities
+
+- [[Terraform]] — Terragrunt 包装的核心引擎
+- [[HashiCorp]] — Terraform 创立公司
+- [[Gruntwork]] — Terragrunt 开发公司
+
+## Related Concepts
+
+- [[Infrastructure-as-Code]] — Terragrunt 的应用领域
+- [[DRY Principle]] — Terragrunt 的设计哲学
+
+## Related Sources
+
+- [[ctp-topic-48-terraform-vs-terragrunt]]
+- [[ctp-topic-3-deploy-and-maintain-infrastructure]]
+- [[ctp-topic-15-working-with-renovatebot]]（Renovate Bot 扫描 Terragrunt 配置）
diff --git a/wiki/index.md b/wiki/index.md
index 745b8d64..5d3f8b2b 100644
--- a/wiki/index.md
+++ b/wiki/index.md
@@ -4,6 +4,14 @@
- [Overview](overview.md) — living synthesis
## Sources
+- [2026-04-24] [CTP Topic 16 Cross-account Terraform modules](sources/ctp-topic-16-cross-account-terraform-modules.md)
+- [2026-04-24] [Learning Sessions ECS Deployment using IAC - 20230808](sources/learning-sessions-ecs-deployment-using-iac-20230808-183322-meeting-recording.md)
+- [2026-04-24] [CTP Topic 48 Terraform vs Terragrunt](sources/ctp-topic-48-terraform-vs-terragrunt.md)
+- [2026-04-24] [Public Cloud Learning Sessions (OpenText) - AI Use Cases - 20241126 160106](sources/public-cloud-learning-sessions-opentext-ai-use-cases-20241126-160106-meeting-rec.md)
+- [2026-04-24] [Public Cloud Learning Sessions (OpenText) - Event Driven Architecture Part 2](sources/public-cloud-learning-sessions-opentext-event-driven-architecture-part-2-2024091.md)
+- [2026-04-24] [Public Cloud Learning Sessions (OpenText) - Generative AI & Prompt Engineering - 20241112](sources/public-cloud-learning-sessions-opentext-generative-ai-prompt-engineering-2024111.md)
+- [2026-04-24] [Public Cloud Learning Sessions (OpenText) - Event Driven Architecture Part 1](sources/public-cloud-learning-sessions-opentext-event-driven-architecture-part-1-2024091.md)
+- [2026-04-24] [Public Cloud Learning Sessions - Serverless Computing - 20240903](sources/public-cloud-learning-sessions-opentext-serverless-computing-20240903-160139-mee.md)
- [2026-04-24] [Public Cloud Learning Sessions - Introduction to AI/ML with AWS](sources/public-cloud-learning-sessions-introduction-to-artificial-intelligence-ai-machin.md)
- [2026-04-24] [Cloud Learning Master Index](sources/cloud-learning-master-index.md)
- [2026-04-24] [CTP Topic 27 AWS Instance Scheduler](sources/ctp-topic-27-aws-instance-scheduler.md)
@@ -406,14 +414,6 @@
- [2026-04-20] [ctp-topic-12-using-ses-smtp-service-terraform-module](sources/ctp-topic-12-using-ses-smtp-service-terraform-module.md) — (expected: wiki/sources/ctp-topic-12-using-ses-smtp-service-terraform-module.md — source missing)
- [2026-04-20] [learning-sessions-cloud-transformation-programme-deploying-rds-via-terraform](sources/learning-sessions-cloud-transformation-programme-deploying-rds-via-terraform.md) — (expected: wiki/sources/learning-sessions-cloud-transformation-programme-deploying-rds-via-terraform.md — source missing)
- [2026-04-20] [learning-sessions-cloud-transformation-programme-20230808-183322-meeting-recordi](sources/learning-sessions-cloud-transformation-programme-20230808-183322-meeting-recordi.md) — (expected: wiki/sources/learning-sessions-cloud-transformation-programme-20230808-183322-meeting-recordi.md — source missing)
-- [2026-04-20] [ctp-topic-16-cross-account-terraform-modules](sources/ctp-topic-16-cross-account-terraform-modules.md) — (expected: wiki/sources/ctp-topic-16-cross-account-terraform-modules.md — source missing)
-- [2026-04-20] [learning-sessions-ecs-deployment-using-iac-20230808-183322-meeting-recording](sources/learning-sessions-ecs-deployment-using-iac-20230808-183322-meeting-recording.md) — (expected: wiki/sources/learning-sessions-ecs-deployment-using-iac-20230808-183322-meeting-recording.md — source missing)
-- [2026-04-19] [ctp-topic-48-terraform-vs-terragrunt](sources/ctp-topic-48-terraform-vs-terragrunt.md) — (expected: wiki/sources/ctp-topic-48-terraform-vs-terragrunt.md — source missing)
-- [2026-04-19] [public-cloud-learning-sessions-opentext-ai-use-cases-20241126-160106-meeting-rec](sources/public-cloud-learning-sessions-opentext-ai-use-cases-20241126-160106-meeting-rec.md) — (expected: wiki/sources/public-cloud-learning-sessions-opentext-ai-use-cases-20241126-160106-meeting-rec.md — source missing)
-- [2026-04-19] [public-cloud-learning-sessions-opentext-event-driven-architecture-part-2-2024091](sources/public-cloud-learning-sessions-opentext-event-driven-architecture-part-2-2024091.md) — (expected: wiki/sources/public-cloud-learning-sessions-opentext-event-driven-architecture-part-2-2024091.md — source missing)
-- [2026-04-19] [public-cloud-learning-sessions-opentext-generative-ai-prompt-engineering-2024111](sources/public-cloud-learning-sessions-opentext-generative-ai-prompt-engineering-2024111.md) — (expected: wiki/sources/public-cloud-learning-sessions-opentext-generative-ai-prompt-engineering-2024111.md — source missing)
-- [2026-04-19] [public-cloud-learning-sessions-opentext-event-driven-architecture-part-1-2024091](sources/public-cloud-learning-sessions-opentext-event-driven-architecture-part-1-2024091.md) — (expected: wiki/sources/public-cloud-learning-sessions-opentext-event-driven-architecture-part-1-2024091.md — source missing)
-- [2026-04-19] [public-cloud-learning-sessions-opentext-serverless-computing-20240903-160139-mee](sources/public-cloud-learning-sessions-opentext-serverless-computing-20240903-160139-mee.md) — (expected: wiki/sources/public-cloud-learning-sessions-opentext-serverless-computing-20240903-160139-mee.md — source missing)
- [Your-AI-Isn-t-Stupid---It-Just-Needs-a-Better-Harness--Lychee-Technology-Engineering-Blog](sources/Your-AI-Isn-t-Stupid---It-Just-Needs-a-Better-Harness--Lychee-Technology-Engineering-Blog.md) — (expected: wiki/sources/Your-AI-Isn-t-Stupid---It-Just-Needs-a-Better-Harness--Lychee-Technology-Engineering-Blog.md — source missing)
- [Expose-hermes-agent-as-an-OpenAI-compatible-API-for-any-frontend](sources/Expose-hermes-agent-as-an-OpenAI-compatible-API-for-any-frontend.md) — (expected: wiki/sources/Expose-hermes-agent-as-an-OpenAI-compatible-API-for-any-frontend.md — source missing)
- [zk-steward](sources/zk-steward.md) — (expected: wiki/sources/zk-steward.md — source missing)
@@ -543,6 +543,7 @@
- [Alertmanager](entities/Alertmanager.md)
- [Alex-Ewerlof](entities/Alex-Ewerlof.md)
- [Alex-Finn](entities/Alex-Finn.md)
+- [Amazon-API-Gateway](entities/Amazon-API-Gateway.md)
- [Amazon-Aurora](entities/Amazon-Aurora.md)
- [Amazon-CloudWatch-Logs](entities/Amazon-CloudWatch-Logs.md)
- [Amazon-DocumentDB](entities/Amazon-DocumentDB.md)
@@ -559,10 +560,13 @@
- [Apache-Superset](entities/Apache-Superset.md)
- [Asana](entities/Asana.md)
- [Ashish](entities/Ashish.md)
+- [Atlantis](entities/Atlantis.md)
- [AWS](entities/AWS.md)
- [AWS-CloudFormation-StackSets](entities/AWS-CloudFormation-StackSets.md)
+- [AWS-Lambda](entities/AWS-Lambda.md)
- [AWS-OpenSearch](entities/AWS-OpenSearch.md)
- [AWS-Organizations](entities/AWS-Organizations.md)
+- [AWS-Step-Functions](entities/AWS-Step-Functions.md)
- [Axton](entities/Axton.md)
- [Azure](entities/Azure.md)
- [baoyu](entities/baoyu.md)
@@ -628,6 +632,7 @@
- [GoogleCloud](entities/GoogleCloud.md)
- [Grafana](entities/Grafana.md)
- [Gruntwork](entities/Gruntwork.md)
+- [HashiCorp](entities/HashiCorp.md)
- [Heather-Norris](entities/Heather-Norris.md)
- [hello-world](entities/hello-world.md)
- [HemantSawant](entities/HemantSawant.md)
@@ -713,6 +718,7 @@
- [rsync](entities/rsync.md)
- [Rufus](entities/Rufus.md)
- [RustDesk](entities/RustDesk.md)
+- [SAM-Serverless-Application-Model](entities/SAM-Serverless-Application-Model.md)
- [SankarGopov](entities/SankarGopov.md)
- [shenwei](entities/shenwei.md)
- [Simon-Hoiberg](entities/Simon-Hoiberg.md)
@@ -730,6 +736,7 @@
- [Synology-NAS-DS718](entities/Synology-NAS-DS718.md)
- [Telnyx](entities/Telnyx.md)
- [Terraform](entities/Terraform.md)
+- [Terragrunt](entities/Terragrunt.md)
- [Tiago-Forte](entities/Tiago-Forte.md)
- [tini](entities/tini.md)
- [Todoist](entities/Todoist.md)
@@ -821,6 +828,7 @@
- [Business-Knowledge-Base](concepts/Business-Knowledge-Base.md)
- [caffeinate](concepts/caffeinate.md)
- [Call-Worthy-Threshold](concepts/Call-Worthy-Threshold.md)
+- [Canary-Deployment](concepts/Canary-Deployment.md)
- [Canary-Release](concepts/Canary-Release.md)
- [Canvas](concepts/Canvas.md)
- [CAPA](concepts/CAPA.md)
@@ -877,6 +885,7 @@
- [Credit-Efficient-Processing](concepts/Credit-Efficient-Processing.md)
- [Cron定时任务](concepts/Cron定时任务.md)
- [Cross-Account-Monitoring](concepts/Cross-Account-Monitoring.md)
+- [Cross-account-Terraform-Modules](concepts/Cross-account-Terraform-Modules.md)
- [Cumulative-Memory](concepts/Cumulative-Memory.md)
- [Custom-Instructions](concepts/Custom-Instructions.md)
- [Daily-Digest](concepts/Daily-Digest.md)
@@ -904,6 +913,7 @@
- [Docker警告处理](concepts/Docker警告处理.md)
- [DORA-Metrics](concepts/DORA-Metrics.md)
- [DRaaS](concepts/DRaaS.md)
+- [DRY-Principle](concepts/DRY-Principle.md)
- [DRY原则](concepts/DRY原则.md)
- [DuckDB](concepts/DuckDB.md)
- [Dynamic-Dashboard](concepts/Dynamic-Dashboard.md)
@@ -923,6 +933,7 @@
- [Error-Budget](concepts/Error-Budget.md)
- [Error-Surface-vs-Root-Cause](concepts/Error-Surface-vs-Root-Cause.md)
- [Event-Correlation](concepts/Event-Correlation.md)
+- [Event-Driven-Architecture](concepts/Event-Driven-Architecture.md)
- [EventSourcing](concepts/EventSourcing.md)
- [Expert-User-Assumption](concepts/Expert-User-Assumption.md)
- [Exporter](concepts/Exporter.md)
diff --git a/wiki/log.md b/wiki/log.md
index 9bb27273..b77e5287 100644
--- a/wiki/log.md
+++ b/wiki/log.md
@@ -1,3 +1,70 @@
+## [2026-05-05] ingest | CTP Topic 16 Cross-account Terraform modules
+- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/03_Terraform/ctp-topic-16-cross-account-terraform-modules.md
+- Status: ✅ 成功摄入
+- Summary: Fibos 主讲，多账号 AWS 环境中跨账号 Terraform 模块的中心化部署方案——基于 Shared Account（共享账号）作为中转站，Jenkins + ECS Deploy Runner + Assume Role 三联动。核心机制：Jenkins 检测 `cross-account.json` 标记文件触发 ECS Deploy Runner，通过 Assume Role 访问目标账号的 TF state bucket accessor 和 cross-account ECS deploy runner role。三大目标：安全性（无 Workload 账号间直接信任）、自动化（Jenkins 自动识别模块类型）、可复用性（模块代码不硬编码特定账号角色）。
+- Concepts created: [[Cross-account-Terraform-Modules]]
+- Entities created: none（Gruntwork 已存在）
+- Source page: wiki/sources/ctp-topic-16-cross-account-terraform-modules.md
+- Notes: index.md 已替换占位符条目；overview.md 已新增独立段落（置于 ECS Deployment 和 Topic 21 之间）；Entity Jenkins/Fibos 提及次数不足建页阈值，以 wikilink 形式记录于 Source page；无实质性内容冲突，演进关系记录于 Contradictions 节
+
+## [2026-05-05] ingest | Learning Sessions ECS Deployment using IAC - 20230808
+- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/03_Terraform/learning-sessions-ecs-deployment-using-iac-20230808-183322-meeting-recording.md
+- Status: ✅ 成功摄入
+- Summary: JP 和 Raja M 主讲，CTP/SRE 团队通过 Terraform IaC 实现 ECS 容器化应用自动化部署——基于 Gruntwork 仓库构建 ECS 模块，支持 Docker 容器/EC2 部署；核心功能：自动扩缩容、自动故障恢复、金丝雀部署；Listener 集中管理方式；前置条件：VPC/ELB 安全组/EFS 卷挂载；集成 CloudWatch/Splunk/Grafana/Prometheus。ECS 作为 AWS 原生技术与 AWS 服务深度集成。
+- Concepts created: [[Canary-Deployment]], [[Infrastructure-as-Code]]
+- Entities created: [[Gruntwork]]
+- Source page: wiki/sources/learning-sessions-ecs-deployment-using-iac-20230808-183322-meeting-recording.md
+- Notes: index.md 已替换占位符条目；overview.md 已新增独立段落（置于 Terraform 工具选型后）；ECS 与 EKS 选型冲突记录于 Contradictions 节；JP 和 Raja M 各出现 1 次，不足独立 Entity 建页阈值，以 wikilink 形式记录于 Source page；无其他内容冲突
+- Conflicts: 与 [[ctp-topic-64-scaling-out-with-amazon-eks]] 在容器编排选型上的差异——ECS 强调 AWS 原生集成，EKS 强调可移植性，两者适用于不同场景但可互补
+
+## [2026-05-05] ingest | CTP Topic 48 Terraform vs Terragrunt
+- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/03_Terraform/ctp-topic-48-terraform-vs-terragrunt.md
+- Status: ✅ 成功摄入
+- Summary: Bob（AWS Solutions Architect）对比 Terraform 与 Terragrunt——Terraform（HashiCorp 出品）是云厂商无关的 Golang 应用，通过状态文件绑定期望状态与实际环境；Terragrunt 是轻量封装，贯彻 DRY 原则，管理 provider 和 remote_state 块减少跨环境重复声明。两者命令和语法高度一致，Terragrunt 通过减少硬编码优化大规模企业部署。辅助工具：Terraform Enterprise、Gruntwork、Atlantis、tfsec、Terratest
+- Concepts created: [[DRY Principle]], [[State-File-Management]]
+- Entities created: [[HashiCorp]], [[Terragrunt]], [[Atlantis]]
+- Entities updated: [[Terraform]], [[Gruntwork]]
+- Concepts updated: [[Infrastructure-as-Code]]
+- Source page: wiki/sources/ctp-topic-48-terraform-vs-terragrunt.md
+- Notes: 视频由 Gemini 摘要，原文状态为 "summarized (Gemini 摘要)"；来源 NAS 路径为 `/volume2/work/Public Cloud Learning Sessions/CTP _ Topic 48_ Terraform vs Terragrunt.mp4`
+
+## [2026-05-05] ingest | Public Cloud Learning Sessions (OpenText) - AI Use Cases - 20241126 160106
+- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/09_Serverless_AI/public-cloud-learning-sessions-opentext-ai-use-cases-20241126-160106-meeting-rec.md
+- Status: ✅ 成功摄入
+- Summary: AWS AI 专家 Stephen Frank 分享 Gen2 AI 发展驱动力（数据爆发+算力提升）、企业级 AI 应用场景（客户体验/洞察提取/流程自动化/内容生成）、AWS 三层产品战略（基础设施→Bedrock→AI 应用）、数据差异化策略（RAG/Fine-tuning/持续预训练）、Amazon Q 企业知识问答、负责任 AI 原则
+- Concepts linked: [[RAG]], [[Fine-Tuning]], [[Continued-Pre-Training]], [[Responsible-AI]]
+- Entities linked: [[AWS]], [[Amazon-Bedrock]], [[Amazon-SageMaker]], [[Amazon-Q]], [[Stephen-Frank]]
+- Source page: wiki/sources/public-cloud-learning-sessions-opentext-ai-use-cases-20241126-160106-meeting-rec.md
+- Notes: index.md 已替换占位符条目（日期修正为 2026-04-14）；overview.md 已新增独立段落（Serverless & AI 专题，置于提示工程后）；RAG/Fine-Tuning/Responsible-AI/Stephen-Frank/Amazon-Q/Amazon-SageMaker 在 wiki 中出现频次不足独立建页阈值，以 wikilink 形式记录于 Source page；无内容冲突
+- Conflicts: 无
+
+## [2026-05-05] ingest | Public Cloud Learning Sessions (OpenText) - Event Driven Architecture Part 2 - 20240917
+- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/09_Serverless_AI/public-cloud-learning-sessions-opentext-event-driven-architecture-part-2-2024091.md
+- Status: ✅ 成功摄入
+- Summary: EDA 进阶实践——三组件（事件生产者/消费者/代理）、事件路由器（EventBridge/SNS）与事件存储（SQS/Kinesis）、编排与编排模式（Choreography vs Orchestration）、幂等性、事件排序、去中心化团队所有权、Fan-out 模式、竞争消费者模式、死信队列、EventBridge 最佳实践
+- Concepts updated: [[Event-Driven-Architecture]]（补充 Part 2 内容：EDA 三组件、编排模式对比、生产级最佳实践：幂等性/事件排序/团队独立性、扩展 Event Patterns：Fan-Out/Competing Consumer/DLQ）
+- Entities existing (no new): [[AWS]], [[Amazon-EventBridge]], [[Amazon-SQS]], [[Amazon-SNS]], [[AWS-Lambda]], [[AWS-Step-Functions]]
+- Source page: wiki/sources/public-cloud-learning-sessions-opentext-event-driven-architecture-part-2-2024091.md
+- Notes: index.md 已替换占位符条目（日期修正为 2026-05-05）；overview.md 已添加 Part 2 独立段落（新增于 Serverless 段落和 Part 1 之间），同时更新 Part 1 引用指向 Part 2；Event-Driven-Architecture 概念页已更新 sources + last_updated，新增 EDA 三组件/编排模式/生产级最佳实践内容，扩展 Event Patterns；Kinesis-Data-Streams 出现 1 次，不足独立建 Entity 阈值，以 wikilink 形式记录于 Concept 页
+- Conflicts: 与 [[ctp-topic-64-scaling-out-with-amazon-eks]] 在扩展方式上的差异——EDA 通过事件驱动异步扩展（消费者按需处理），EKS 通过容器编排横向扩展（Pod 副本数调整），两者适用于不同场景但可互补使用
+- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/09_Serverless_AI/public-cloud-learning-sessions-opentext-event-driven-architecture-part-1-2024091.md
+- Status: ✅ 成功摄入
+- Summary: EDA 入门——AWS 解决方案架构师 Dr. Anil Giri 介绍 EventBridge/SQS/SNS 事件驱动架构与 Enterprise Integration Patterns；会议因 Teams 屏幕共享故障仅完成开场介绍，完整演示参见 Part 2
+- Concepts linked: [[Event-Driven-Architecture]], [[Enterprise-Integration-Patterns]], [[Amazon-EventBridge]], [[Amazon-SQS]], [[Amazon-SNS]]
+- Entities linked: [[Dr.-Anil-Giri]], [[AWS]], [[OpenText]], [[Micro-Focus]]
+- Source page: wiki/sources/public-cloud-learning-sessions-opentext-event-driven-architecture-part-1-2024091.md
+- Notes: index.md 已替换占位符条目（日期修正为 2026-04-19）；overview.md 已补充（Serverless & AI 专题段落新增，置于无服务器计算后）；Dr. Anil Giri/AWS/OpenText/Micro Focus 在 wiki 中出现频次不足独立建 Entity 页阈值，以 wikilink 形式记录于 Source page；EventBridge/SQS/SNS/Enterprise-Integration-Patterns 概念频次不足独立建 Concept 页阈值；已建立与 Part 2（public-cloud-learning-sessions-opentext-event-driven-architecture-part-2-2024091）、无服务器计算（public-cloud-learning-sessions-opentext-serverless-computing-20240903-160139-mee）的 Connections 关系；冲突记录与 ctp-topic-64-scaling-out-with-amazon-eks 的扩展方式差异已记录于 Contradictions 节
+- Conflicts: 与 [[ctp-topic-64-scaling-out-with-amazon-eks]] 在扩展方式上的差异——EDA 通过事件驱动异步扩展，EKS 通过容器编排横向扩展，两者适用于不同场景但可互补使用
+
+## [2026-05-05] ingest | Public Cloud Learning Sessions - Serverless Computing - 20240903
+- Status: ✅ 成功摄入
+- Summary: AWS 无服务器计算深度解析——Lambda 事件驱动模型（同步/异步/事件源映射）、Step Functions 状态机编排（Standard/Express）、API Gateway（边缘优化/区域/私有）、SAM 本地开发和部署；Serverless 业务价值（快速上市/按需付费/自动扩展/内置安全）；AWS 与客户共担运维责任
+- Entities created: [[AWS-Lambda]], [[AWS-Step-Functions]], [[Amazon-API-Gateway]], [[SAM-Serverless-Application-Model]]
+- Concepts linked: [[Serverless-Computing]], [[Event-Driven-Architecture]]
+- Source page: wiki/sources/public-cloud-learning-sessions-opentext-serverless-computing-20240903-160139-mee.md
+- Notes: index.md 已更新（替换占位符条目，日期修正为 2026-04-14）；overview.md 已补充（Cloud Transformation & DevOps 章节新增独立段落，置于 AI/ML 入门与 CTP Topic 20 之间）；Entity 页均按字母顺序插入 index.md Entities 节；无内容冲突（Serverless-Computing 概念页已存在，内容一致）
+- Conflicts: 无
+
## [2026-05-05] ingest | Public Cloud Learning Sessions - Introduction to AI/ML with AWS
- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/09_Serverless_AI/public-cloud-learning-sessions-introduction-to-artificial-intelligence-ai-machin.md
- Status: ✅ 成功摄入
@@ -2512,4 +2579,19 @@
- overview.md 更新：新增条目于 Cloud Transformation & DevOps 章节 FinOps 知识链路
- RightSizing/Cloud Cost Optimization 已通过 wikilink 嵌入 Source page
- Key Entities: PCG (Platform Control Group) 已在 Wiki 中存在（ctp-topic-13），无需新建 Entity 页面
- - 冲突检测：未发现内容冲突，Contradictions 暂置空占位
\ No newline at end of file
+ - 冲突检测：未发现内容冲突，Contradictions 暂置空占位
+
+## [2026-05-06] ingest | Public Cloud Learning Sessions (OpenText) - Generative AI & Prompt Engineering - 20241112
+- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/09_Serverless_AI/public-cloud-learning-sessions-opentext-generative-ai-prompt-engineering-2024111.md
+- Status: ✅ 成功摄入
+- Summary: AWS 生成式 AI 服务与提示工程实践，由 OpenText 技术客户经理 Shikad Holtzman（以色列）主讲——生成式 AI 四大价值路径、企业数据差异化核心洞见、Amazon Bedrock 全托管基础模型服务（RAG/微调/Agents/Guardrails）、Amazon Q 助手（企业版/开发者版）、AWS 专用芯片（Trainium/Inferentia）、提示工程四组件（指令/上下文/用户输入/输出指示器）和基础技巧（One-shot/Few-shot、Chain of Thoughts）
+- Concepts linked: [[RAG]], [[Prompt-Engineering]], [[Chain-of-Thought]], [[One-Shot-Prompting]], [[Few-Shot-Prompting]], [[Responsible-AI]], [[Guardrails-for-Amazon-Bedrock]]
+- Entities linked: [[Shikad-Holtzman]], [[Amazon-Bedrock]], [[Amazon-SageMaker]], [[Amazon-Q]], [[AWS-Trainium]], [[AWS-Inferentia]], [[AWS]]
+- Source page: wiki/sources/public-cloud-learning-sessions-opentext-generative-ai-prompt-engineering-2024111.md
+- Notes:
+ - index.md 已更新：将原 expected placeholder 更新为正式条目（2026-04-19），补充中文摘要
+ - overview.md 已更新：在 Cloud Transformation & DevOps 章节的 AI/ML 入门条目后新增独立段落，与 AI/ML 入门共同构成生成式 AI 知识链路
+ - Key Concepts：RAG/Prompt-Engineering/Chain-of-Thought/Few-Shot-Prompting 频次不足独立建 Concept 页阈值，以 wikilink 形式记录于 Source page
+ - Key Entities：Shikad Holtzman 仅出现 1 次，以 wikilink 形式记录于 Source page；Amazon Bedrock/Q/SageMaker 在同系列其他来源中提及频次不足独立建 Entity 页阈值
+ - 同系列来源关联：已建立与 AI/ML 入门（public-cloud-learning-sessions-introduction-to-artificial-intelligence-ai-machin）和无服务器计算（public-cloud-learning-sessions-opentext-serverless-computing-20240903-160139-mee）的 Connections 关系
+ - 冲突检测：与 ctp-topic-64-scaling-out-with-amazon-eks 在扩展方式上的差异已记录于 Source page Contradictions（EDA 事件驱动 vs EKS 容器编排，适用于不同场景可互补）
\ No newline at end of file
diff --git a/wiki/overview.md b/wiki/overview.md
index 328df74a..37e5c0fa 100644
--- a/wiki/overview.md
+++ b/wiki/overview.md
@@ -53,7 +53,13 @@ Cloud Transformation Programme (CTP) materials cover AWS landing zones, EKS, Ter
**[[ctp-topic-15-working-with-renovatebot]]**（CTP Topic 15）：Paul Hopkins 主讲 Renovate Bot 自动化依赖项更新——解决"依赖地狱"问题，实时扫描 Docker 镜像/Terraform 模块/Terragrunt 配置/pre-commit 钩子等版本标签，自动发起 Pull Request；通过 Dependency Dashboard 提供全局依赖状态视图；集成 Jenkins 流水线，使用 Podman 容器化运行并配置 Rate Limiting 避免 PR 风暴；提升基础设施安全性（及时修复漏洞）和配置一致性。属 [[GitOps]] 和 [[CI/CD Pipeline]] 的依赖治理层，与 [[ctp-topic-9-ci-cd-with-gruntwork]]（Gruntwork CI/CD）和 [[ctp-topic-33-an-introduction-to-gitops]]（GitOps 入门）共同构成完整的 IaC 知识链路。
-**[[ctp-topic-56-automated-infrastructure-testing]]**（CTP Topic 56）：Mark Francis 主讲自动化基础设施测试——将软件测试原则应用于 Terraform IaC 代码，通过 TerraTest（Golang 框架）实现 apply → test → destroy 自动化验证循环。核心主张：集成测试超越语法检查，验证实际部署行为是否符合预期；倡导测试驱动开发（TDD）应用于 IaC 领域，先写测试再实现功能；提议将测试编写作为基础设施开发的首要步骤，移除手动验证，追求自动化验证套件和更高的部署信心。核心价值观："让机器做重复的事，把人脑留给复杂的人类问题"。属 [[GitOps]] 和 [[CI/CD Pipeline]] 的质量保障层，与 [[ctp-topic-33-an-introduction-to-gitops]]（GitOps 概念）和 [[ctp-topic-32-using-atlantis-cicd-for-infrastructure-deployments]]（Atlantis 工具）共同构成完整的 IaC 质量保障链路。
+**[[ctp-topic-56-automated-infrastructure-testing]]**（CTP Topic 56）：Mark Francis 主讲自动化基础设施测试——将软件测试原则应用于 Terraform IaC 代码，通过 TerraTest（Golang 框架）实现 apply → test → destroy 自动化验证循环。核心主张：集成测试超越语法检查，验证实际部署行为是否符合预期；倡导测试驱动开发（TDD）应用于 IaC 领域，先写测试再实现功能；提议将测试编写作为基础设施开发的首要步骤，移除手动验证，追求自动化验证套件和更高的部署信心。核心价值观："让机器做重复的事，把人脑留给复杂的人类问题"。属 [[GitOps]] 和 [[CI/CD Pipeline]] 的质量保障层，与 [[ctp-topic-33-an-introduction-to-gitops]]（GitOps 概念）和 [[ctp-topic-32-using-atlantis-cicd-for-infrastructure-deployments]]（Atlantis 工具）共同构成 IaC 知识体系。
+
+**[[ctp-topic-48-terraform-vs-terragrunt]]**（CTP Topic 48）：Bob（AWS Solutions Architect）对比 Terraform 与 Terragrunt——Terraform（HashiCorp 出品）是云厂商无关的 Golang 应用，通过状态文件将期望状态与实际环境绑定，企业级使用须将状态文件存储在安全可访问位置；Terragrunt 是 Terraform 的轻量封装，贯彻 DRY 原则，通过管理 provider 和 remote_state 块减少跨环境的重复声明。两者命令和语法高度一致（`terraform plan` = `terragrunt plan`），Terragrunt 通过减少硬编码来优化大规模企业部署。辅助工具：Terraform Enterprise（CI 平台 + workspaces）、Gruntwork（预建可定制模块）、Atlantis（Git 集成）、tfsec（静态安全分析）、Terratest（IaC 测试自动化）。属 [[Infrastructure As Code]] 工具选型层，与 [[ctp-topic-3-deploy-and-maintain-infrastructure]]（Terragrunt HCL）和 [[ctp-topic-56-automated-infrastructure-testing]]（Terratest）共同构成 Terraform 生态知识链路。
+
+**（本条新增）Learning Sessions ECS Deployment using IAC**（2023-08-08）：JP 和 Raja M 主讲，CTP/SRE 团队通过 Terraform IaC 实现 ECS 容器化应用自动化部署——基于 Gruntwork 仓库构建的 ECS 模块，将 Docker 容器作为逻辑单元，支持 EC2 实例部署；核心功能：自动扩缩容、自动故障恢复、金丝雀部署；通过 Listener 方式集中管理（避免各产品团队重复下载 Gruntwork 代码）；前置条件包括 VPC、ELB 安全组和 EFS 卷挂载；集成 CloudWatch/Splunk/Grafana/Prometheus。ECS 作为 AWS 原生技术与 AWS 服务深度集成，适合追求简单性和紧密集成的场景；属 [[Infrastructure-as-Code]] 在 ECS 场景的实践，与 [[ctp-topic-70-eks-deployment-using-iac]]（EKS IaC 部署）构成容器编排双路径，与 [[ctp-topic-9-ci-cd-with-gruntwork]]（Gruntwork CI/CD）共享 Gruntwork 基础设施基础。与 [[ctp-topic-67-cloud-native-observability-using-opentelemetry]] 在可观测性集成方面关联（ECS 模块集成 CloudWatch/Grafana）。
+
+**[[ctp-topic-16-cross-account-terraform-modules]]**（CTP Topic 16）：Fibos 主讲，多账号 AWS 环境中跨账号 Terraform 模块的中心化部署方案——解决原有 Gruntwork 流水线主要针对单账号设计、账号间直接互访存在安全风险（Blast Radius）的问题。核心架构：基于 **Shared Account（共享账号）** 作为中转站，Jenkins 托管于 Shared Account，检测到模块目录中 `cross-account.json` 标记文件后触发 **ECS Deploy Runner**（ECS 上的 Docker 容器）；该 Runner 通过 Assume Role 访问目标账号的两个角色——`TF state bucket accessor`（读取状态文件）和 `cross-account ECS deploy runner role`（执行资源部署）；角色切换逻辑在根目录 `terragrunt.hcl` 中全局配置。实现三大目标：**安全性**（无 Workload 账号间直接信任）、**自动化**（Jenkins 自动识别模块类型）、**可复用性**（模块代码不硬编码特定账号角色）。属 [[Infrastructure-as-Code]] 在多账号场景的进阶实践，与 [[ctp-topic-9-ci-cd-with-gruntwork]]（单账号流水线）构成演进关系，与 [[ctp-topic-32-using-atlantis-cicd-for-infrastructure-deployments]]（Atlantis 跨账号角色）共享 Assume Role 机制但执行载体不同（ECS 容器 vs EC2），与 [[ECS Deploy Runner]]（实体）共同构成跨账号部署完整链路。
**[[ctp-topic-21-supply-chain-security-in-micro-focus]]**（CTP Topic 21）：
@@ -185,7 +191,17 @@ Key concepts: [[Process]], [[Value]], [[Value-Stream]], [[Value-Adding]], [[Wast
**[[public-cloud-learning-sessions-best-practices-for-ec2-cost-optimization-in-aws-2]]**（Public Cloud Learning Sessions，Mike Dukes 和 Steele Taylor 主讲）：AWS EC2 成本优化最佳实践深度解析——核心主题覆盖计算效率、Nitro 系统、Graviton 使用、EC2 Spot 竞价实例和容器化成本部署。AWS Nitro 系统通过将网络、存储和安全组件外部化来提升效率；Graviton 处理器基于 ARM64 架构，提供高达 40% 更好的性价比，功耗比同等 x86 实例减少高达 60%；EC2 Spot 实例利用 AWS 闲置容量提供高达 90% 的按需价格折扣；购买选项包括 On-Demand、Savings Plans 和 Spot Instances。Spot Invaders 游戏作为容错混沌工程的实践案例，展示了在 EKS 上使用 Spot 实例构建弹性应用的最佳实践。Graviton 适用于大多数工作负载（Web 服务、容器、HPC 批处理、大数据、CI/CD），但排除有状态服务（如数据库）；Spot 和 Graviton 可组合使用以最大化成本节省。属 [[FinOps（云财务管理）]] 技术实践层，与 [[public-cloud-learning-sessions-reducing-cloud-costs-20250318-170100-meeting-reco]]（成本优化技术）和 [[ctp-topic-13-cloud-finops-policies]]（政策框架）共同构成完整的 EC2 成本优化知识链路。
-**[[public-cloud-learning-sessions-introduction-to-artificial-intelligence-ai-machin]]**（Public Cloud Learning Sessions，AWS 高级解决方案架构师 Suraav Paul 主讲）：AWS AI/ML 与生成式 AI 入门——AI 复制需要人类智能的任务，通过机器学习使用数据创建决策模型；分类 AI 识别模式，预测 AI 预判趋势，生成式 AI 利用基础模型（Foundation Models）创造内容。Amazon 在 ML 领域深耕 20 年，AWS 在四大领域帮助客户应用 AI：提升客户体验、实现更优决策、改善运营、创造新产品。Amazon Bedrock 是全托管生成式 AI 服务，提供 Titan 等多种基础模型，支持微调、持续预训练、RAG 和 Bedrock Agents 等数据定制技术；Guardrails for Bedrock 提供负责任 AI 安全护栏。ML Ops 将机器学习与运维融合，涵盖数据流水线（数据收集/集成/准备）、训练流水线（特征工程/模型训练/超参调优）和推理流水线（部署/监控）。属 Cloud Transformation Programme 的 Serverless & AI 专题入门，与 [[public-cloud-learning-sessions-opentext-generative-ai-prompt-engineering-2024111]]（Prompt Engineering）和 [[public-cloud-learning-sessions-opentext-serverless-computing-20240903-160139-mee]]（无服务器计算）共同构成 Serverless & AI 知识链路。
+**[[public-cloud-learning-sessions-introduction-to-artificial-intelligence-ai-machin]]**（Public Cloud Learning Sessions，AWS 高级解决方案架构师 Suraav Paul 主讲）：AWS AI/ML 与生成式 AI 入门——AI 复制需要人类智能的任务，通过机器学习使用数据创建决策模型；分类 AI 识别模式，预测 AI 预判趋势，生成式 AI 利用基础模型（Foundation Models）创造内容。Amazon 在 ML 领域深耕 20 年，AWS 在四大领域帮助客户应用 AI：提升客户体验、实现更优决策、改善运营、创造新产品。Amazon Bedrock 是全托管生成式 AI 服务，提供 Titan 等多种基础模型，支持微调、持续预训练、RAG 和 Bedrock Agents 等数据定制技术；Guardrails for Bedrock 提供负责任 AI 安全护栏。ML Ops 将机器学习与运维融合，涵盖数据流水线（数据收集/集成/准备）、训练流水线（特征工程/模型训练/超参调优）和推理流水线（部署/监控）。属 Cloud Transformation Programme 的 Serverless & AI 专题入门，与 [[public-cloud-learning-sessions-opentext-generative-ai-prompt-engineering-2024111]]（Generative AI & Prompt Engineering，OpenText 技术客户经理 Shikad Holtzman 主讲）和 [[public-cloud-learning-sessions-opentext-serverless-computing-20240903-160139-mee]]（无服务器计算）共同构成 Serverless & AI 知识链路。
+
+**[[public-cloud-learning-sessions-opentext-generative-ai-prompt-engineering-2024111]]**（Public Cloud Learning Sessions，OpenText 技术客户经理 Shikad Holtzman 主讲）：AWS 生成式 AI 服务与提示工程实践——Shikad Holtzman 阐述生成式 AI 四大价值路径（新体验/员工生产力/洞察提取/创造力激发），涵盖客服聊天机器人、代码生成摘要、文档处理和图像生成等行业场景；核心洞见：**企业数据是差异化关键**，通过 Amazon Bedrock 连接自有数据（无需重训练）即可构建专属生成式 AI 应用，且 Bedrock 保证用户数据与提示词绝不与模型提供商共享。Amazon Bedrock 提供来自 Anthropic/Meta/Amazon Titan 的多种基础模型（含多模态），内置 RAG 知识库、微调、Agents 和 Guardrails for Bedrock 自定义有害内容过滤；Amazon Q 分企业版（多数据源搜索/摘要）和开发者版（代码生成/单元测试/代码迁移）；AWS 专用训练芯片 Trainium 和推理芯片 Inferentia 支撑底层算力。提示工程（Prompt Engineering）是创建、设计和优化提示词引导 LLM 响应的迭代过程，提示由指令、上下文、用户输入和输出指示器四部分组成；基础技巧包括 One-shot/Few-shot（通过示例引导）和 Chain of Thoughts（逐步推理解决复杂任务）。属 Cloud Transformation Programme 的 Serverless & AI 专题，与 [[public-cloud-learning-sessions-introduction-to-artificial-intelligence-ai-machin]]（AI/ML 入门）共同构成生成式 AI 知识链路。
+
+**[[public-cloud-learning-sessions-opentext-ai-use-cases-20241126-160106-meeting-rec]]**（Public Cloud Learning Sessions，AWS AI 专家 Stephen Frank 主讲）：AWS Gen2 AI 发展驱动力与企业在生产中的 AI 应用场景——Stephen Frank 阐述 AI 演进历程（模仿人类行为 → 机器学习 → 深度学习 → Gen2 大语言模型），Gen2 AI 崛起背后的两大驱动力：2000 年代以来数据爆发式增长和更大算力的可获得性。Amazon 在核心产品和服务中应用 AI/ML 已 25 年，将经验应用于新客户产品。通用 AI 应用场景：创造新客户体验、从数据中推断核心洞察、流程自动化、生成新内容；企业软件场景：优化内部流程、启用新功能、创造新产品。**数据是差异化关键**——生成式 AI 应用通过 RAG / Fine-tuning / 持续预训练与企业现有业务数据集成。AWS 三层产品战略：基础设施层（基础模型训练/推理）→ Amazon Bedrock（旗舰 API 访问，承诺不与第三方共享用户数据，符合 GDPR）→ 即用型 AI 应用（Amazon Q 等）。Amazon Bedrock 保证用户数据与提示词不与第三方模型提供商共享；Amazon Q 通过自然语言连接多种企业数据源（知识摘要/内容创建/洞察提取）。AI 实施关键：培育实验文化、灵活选择模型、重视安全治理与合规；负责任 AI 原则：公平性（Fairness）、可解释性（Explainability）、透明度（Transparency）；最佳实践：优先考虑人、评估风险、迭代全生命周期。属 Cloud Transformation Programme 的 Serverless & AI 专题，与 [[public-cloud-learning-sessions-introduction-to-artificial-intelligence-ai-machin]]（AI/ML 入门）和 [[public-cloud-learning-sessions-opentext-generative-ai-prompt-engineering-2024111]]（提示工程）共同构成完整的 AI 知识链路。
+
+**[[public-cloud-learning-sessions-opentext-serverless-computing-20240903-160139-mee]]**（Public Cloud Learning Sessions，OpenText）：AWS 无服务器计算深度解析——现代企业面临快速创新、安全合规、事件响应和盈利增长的多重压力，Serverless 计算通过将运维任务转移给云厂商，使开发团队专注业务代码。AWS Lambda 是核心服务，开发者只需编写业务逻辑，AWS 负责负载均衡、自动扩展和安全，函数由事件（状态变化）触发，支持同步、异步和事件源映射三种调用模式；Lambda 权限模型分离执行角色（决定函数能调用哪些资源）和资源策略（决定谁能触发函数），版本、别名和 Layers 支持代码管理和复用，ARM64 架构提供更优性价比。Step Functions 基于状态机编排多个 Lambda 函数和 AWS 服务，提供 Standard（长时）和 Express（高频）两种工作流类型；API Gateway 提供边缘优化、区域和私有三种部署选项管理 API 生命周期；SAM（Serverless Application Model）基于 CloudFormation 构建，支持本地开发和测试。属 Cloud Transformation Programme 的 Serverless & AI 专题，与 [[public-cloud-learning-sessions-introduction-to-artificial-intelligence-ai-machin]]（AI/ML 入门）共同构成 Serverless & AI 知识链路，与 [[public-cloud-learning-sessions-opentext-event-driven-architecture-part-1-2024091]]（事件驱动架构 Part 1）和 [[public-cloud-learning-sessions-opentext-event-driven-architecture-part-2-2024091]]（事件驱动架构 Part 2）共享事件驱动执行模型。
+
+**[[public-cloud-learning-sessions-opentext-event-driven-architecture-part-2-2024091]]**（Public Cloud Learning Sessions，AWS 解决方案架构师 Dr. Anil Giri 主讲）：事件驱动架构（EDA）进阶实践——详解 EDA 三组件（事件生产者/消费者/代理）、事件路由器（EventBridge/SNS）与事件存储（SQS/Kinesis）、编排与编排模式（Choreography vs Orchestration）、幂等性（Idempotency）、事件排序（SQS FIFO/Kinesis 保证顺序）、团队独立性（去中心化所有权 vs 集中式所有权）、Fan-out 模式（SNS 主题/EventBridge 规则）、竞争消费者模式（SQS）、死信队列（DLQ）和 EventBridge 最佳实践（每个订阅者单条规则、避免默认事件总线、失败事件处理）。核心洞见：**"Everything fails every time"**——任何系统任何时刻都可能故障，因此幂等性和 DLQ 是 EDA 生产级落地的必要保障。属 Cloud Transformation Programme 的 Serverless & AI 专题进阶篇，与 [[public-cloud-learning-sessions-opentext-event-driven-architecture-part-1-2024091]]（Part 1）构成完整 EDA 知识体系，与 [[public-cloud-learning-sessions-opentext-serverless-computing-20240903-160139-mee]]（无服务器计算）共享 Lambda 事件驱动执行模型。
+
+**[[public-cloud-learning-sessions-opentext-event-driven-architecture-part-1-2024091]]**（Public Cloud Learning Sessions，AWS 解决方案架构师 Dr. Anil Giri 主讲）：事件驱动架构（EDA）入门与概述——核心学习目标：掌握企业级集成模式（Enterprise Integration Patterns），通过 Amazon EventBridge、SQS 和 SNS 探索事件驱动架构以解决现实世界中的业务挑战。会议原定演示具体 EDA 架构组件，但因 Teams 屏幕共享故障，仅完成开场介绍（⚠️ 完整演示内容参见 [[public-cloud-learning-sessions-opentext-event-driven-architecture-part-2-2024091]]）。属 Cloud Transformation Programme 的 Serverless & AI 专题，与 [[public-cloud-learning-sessions-opentext-serverless-computing-20240903-160139-mee]]（无服务器计算）共享事件驱动执行模型，共同构成 Serverless & AI 知识链路。
**[[ctp-topic-20-program-demand-process-flow-and-poc-onboarding]]**（CTP Topic 20）：云转型计划的程序需求流程与 POC 入职流程——Sergio 和 Damian 主讲。核心内容：①需求来源——主要由业务案例（如数据中心关闭）、高层管理人员战略优先级及产品路线图驱动；②Gate Process——Gate 0 评估准入、Gate 1 负责 Design Authority 审批、Gate 3 作为启动迁移的最终准入；③POC 目的——不仅验证架构和技术可行性，还包括让团队熟悉基于 Gruntwork 的新一代 Landing Zone；④新环境特点——强调 IaC（Terraform/Terragrunt）自动化部署，严禁手动构建；⑤PCG 团队——平台控制组，负责提供云环境支持、安全策略制定及协助产品组进行 POC；⑥成功标准——POC 成功标准必须在启动前明确定义。属 CTP 治理知识体系入口，与 [[ctp-topic-65]]（价值量化）、[[ctp-topic-57]]（需求管理）、[[ctp-topic-30]]（变更管理）共同构成完整的治理框架链条。
diff --git a/wiki/sources/ctp-topic-16-cross-account-terraform-modules.md b/wiki/sources/ctp-topic-16-cross-account-terraform-modules.md
new file mode 100644
index 00000000..982266f9
--- /dev/null
+++ b/wiki/sources/ctp-topic-16-cross-account-terraform-modules.md
@@ -0,0 +1,55 @@
+---
+title: "CTP Topic 16 Cross-account Terraform modules"
+type: source
+tags: [Terraform, Cross-Account, Modules, CTP, IaC, DevOps, AWS-Landing-Zone]
+date: 2026-04-14
+---
+
+## Source File
+- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/03_Terraform/ctp-topic-16-cross-account-terraform-modules]]
+
+## Summary（用中文描述）
+- 核心主题：**跨账号 Terraform 模块的中心化部署方案**，解决多账号 AWS 环境中一个模块内跨账号创建资源的安全与自动化问题
+- 问题域：原有的 Gruntwork 流水线针对单账号设计，在多账号场景下存在安全风险（一账号被攻破可能波及全局）
+- 方法/机制：基于 **Shared Account（共享账号）** 的中心化部署架构，Jenkins + ECS Deploy Runner + Assume Role 三者联动
+- 结论/价值：实现安全性（账号间无直接信任关系）、自动化（Jenkins 自动识别跨账号模块）、可复用性（模块代码不硬编码特定账号角色）
+
+## Key Claims（用中文描述）
+- **Shared Account 作为中转站**：Jenkins 托管在 Shared Account，当检测到 `cross-account.json` 标记文件时触发 ECS Deploy Runner
+- **Assume Role 双角色机制**：ECS Deploy Runner 通过 Assume Role 访问目标账号的两个角色——`TF state bucket accessor`（读取状态文件）和 `cross-account ECS deploy runner role`（执行资源部署）
+- **Blast Radius 控制**：避免 Workload 账号之间直接互访，权限控制在受严格审计的 Shared Account
+- **Terragrunt HCL 全局配置**：通过根目录 `terragrunt.hcl` 定义远程状态存储和角色切换逻辑，支持本地开发与 Jenkins 自动部署的差异化角色处理
+
+## Key Quotes
+> "Cross-account Terraform Modules 指在一个模块内通过配置多个 Provider，实现在多个 AWS 账号中同时创建或管理资源的功能" — Fibos，核心概念定义
+> "Shared Account 是整个 Landing Zone 的核心管理账号，托管 Jenkins、镜像仓库等公共服务，并作为跨账号部署的信任源" — Fibos，架构定位
+> "ECS Deploy Runner 运行在 ECS 上的 Docker 容器，负责执行 Terraform plan 和 apply 命令，是流水线中的实际执行单元" — Fibos，EDR 定义
+
+## Key Concepts
+- [[Cross-account Terraform Modules]]：在一个 Terraform 模块中通过配置多个 Provider，实现在多个 AWS 账号中同时创建或管理资源的功能
+- [[Shared Account]]：Landing Zone 核心管理账号，托管 Jenkins 及公共服务，作为跨账号部署的信任源
+- [[ECS Deploy Runner]]：运行在 ECS 上的 Docker 容器，负责执行 Terraform plan/apply，是流水线的实际执行单元
+- [[TF State Bucket Accessor]]：专门定义的 IAM 角色，仅允许部署工具访问目标账号 S3 桶中的 Terraform 状态文件
+- [[Cross-account ECS Deploy Runner Role]]：部署在目标账号中的角色，允许 Shared Account 的执行器通过 Assume Role 获取资源创建权限
+- [[cross-account.json]]：约定俗成的标记文件，放置于模块目录中，用于告知 Jenkins 该模块需要调用跨账号部署逻辑
+- [[Root Terragrunt HCL]]：全局 Terragrunt 配置文件，定义远程状态存储和角色切换逻辑
+
+## Key Entities
+- **Fibos**：主讲人，分享了团队基于 Shared Account 的跨账号 Terraform 部署方案
+- **Gruntwork**：参考架构来源，原有 Gruntwork 流水线主要针对单账号设计
+- **Jenkins**：CI/CD 引擎，托管在 Shared Account，负责检测模块类型并触发部署流程
+- **AWS Landing Zone**：多账号架构框架，Shared Account + Workload Account 的分层设计
+
+## Connections
+- [[ctp-topic-9-ci-cd-with-gruntwork]] ← foundation ← [[ctp-topic-16-cross-account-terraform-modules]]
+- [[ECS Deploy Runner]] ← depends_on ← [[Shared Account]]
+- [[Cross-account Terraform Modules]] ← uses ← [[ECS Deploy Runner]]
+- [[ECS Deploy Runner]] ← assumes ← [[Cross-account ECS Deploy Runner Role]]
+- [[ECS Deploy Runner]] ← reads_state ← [[TF State Bucket Accessor]]
+- [[Root Terragrunt HCL]] ← configures ← [[Cross-account Terraform Modules]]
+- [[ctp-topic-48-terraform-vs-terragrunt]] ← related ← [[Root Terragrunt HCL]]
+- [[AWS-Landing-Zone]] ← enables ← [[Shared Account]]
+
+## Contradictions
+- 与 [[ctp-topic-9-ci-cd-with-gruntwork]]（单账号 Gruntwork 流水线）：原有 Gruntwork 流水线主要针对单账号设计，不处理跨账号场景；本方案通过 Shared Account 中心化架构扩展支持多账号，同时保留 Gruntwork 模块复用优势。两者为演进关系而非冲突。
+- 与 [[ctp-topic-32-using-atlantis-cicd-for-infrastructure-deployments]]（Atlantis 替代 Jenkins）：Atlantis 在 merge 前应用变更，每个 Landing Zone 部署单台 EC2 实例；本方案的 ECS Deploy Runner 运行在容器中，更适合跨账号大规模部署。Atlantis 的跨账号访问通过各账户 IAM 角色实现，与本方案 Assume Role 机制类似，但执行载体不同。
diff --git a/wiki/sources/ctp-topic-48-terraform-vs-terragrunt.md b/wiki/sources/ctp-topic-48-terraform-vs-terragrunt.md
new file mode 100644
index 00000000..be3b2062
--- /dev/null
+++ b/wiki/sources/ctp-topic-48-terraform-vs-terragrunt.md
@@ -0,0 +1,55 @@
+---
+title: "CTP Topic 48 Terraform vs Terragrunt"
+type: source
+tags:
+ - Terraform
+ - Terragrunt
+ - IaC
+ - DevOps
+ - CTP
+date: 2026-04-14
+---
+
+## Source File
+- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/03_Terraform/ctp-topic-48-terraform-vs-terragrunt.md]]
+
+## Summary（用中文描述）
+- 核心主题：Terraform 与 Terragrunt 的对比选型，涵盖企业级 IaC 实践
+- 问题域：多环境配置管理、基础设施代码复用、状态文件管理
+- 方法/机制：Terraform 作为核心 IaC 工具（云厂商无关），Terragrunt 作为 Terraform 的 DRY 封装层，处理跨环境变量和远程状态的重复声明
+- 结论/价值：Terraform 与 Terragrunt 命令和语法高度一致，但 Terragrunt 通过减少硬编码、提升可复用性来优化大规模企业部署；两者可互补使用
+
+## Key Claims（用中文描述）
+- Terraform（HashiCorp 出品）通过状态文件将期望状态与现有环境绑定，企业级使用须将状态文件存储在安全可访问的位置
+- Terragrunt 是 Terraform 的轻量封装，贯彻 DRY 原则，通过管理 provider 和 remote_state 块减少跨环境的重复声明
+- Terraform Enterprise 提供带 workspace 的 CI 平台，Gruntwork 提供预建可定制模块，Atlantis 实现 Git 驱动的自动化部署
+- tfsec 用于静态代码安全分析，Terratest 用于基础设施测试自动化
+
+## Key Quotes
+> "Terraform ties the desired state to the existing environment using a state file. For enterprise-scale use, storing this file in a safe, accessible location is crucial." — Bob, AWS Solutions Architect
+> "Terragrunt offers a way to use information in a repeatable way without hard coding values." — Bob
+> "All Terraform commands work with Terragrunt; a Terraform plan becomes a Terragrunt plan." — Bob
+
+## Key Concepts
+- [[Infrastructure As Code]]：通过代码定义和版本控制基础设施资源的实践
+- [[DRY Principle]]：Don't Repeat Yourself — 避免重复配置，通过抽象层复用
+- [[State File Management]]：Terraform 用状态文件绑定期望状态与实际环境
+- [[IaC Testing]]：用 Terratest 等工具对基础设施代码进行自动化测试
+
+## Key Entities
+- [[HashiCorp]]：Terraform 创立公司，提供多云基础设施编排工具
+- [[Gruntwork]]：提供预建可定制的 Terraform 模块和 Terraform 原生 AWS Landing Zone
+- [[Atlantis]]：将 Terraform 与 GitHub 集成的开源 CI/CD 工具
+- [[Terraform]]：云厂商无关的基础设施即代码工具
+- [[Terragrunt]]：Terraform 的 DRY 封装层，管理多环境配置
+
+## Connections
+- [[Terraform]] ← uses ← [[State File Management]]
+- [[Terragrunt]] ← wraps ← [[Terraform]]
+- [[Terraform]] ← provided_by ← [[HashiCorp]]
+- [[Gruntwork]] ← provides_modules_for ← [[Terraform]]
+- [[Atlantis]] ← integrates_with ← [[Terraform]]
+- [[Terraform]] ← related_concept ← [[Infrastructure As Code]]
+
+## Contradictions
+- 暂无发现与其他 Wiki 页面的直接冲突
diff --git a/wiki/sources/learning-sessions-ecs-deployment-using-iac-20230808-183322-meeting-recording.md b/wiki/sources/learning-sessions-ecs-deployment-using-iac-20230808-183322-meeting-recording.md
new file mode 100644
index 00000000..e33d5a2d
--- /dev/null
+++ b/wiki/sources/learning-sessions-ecs-deployment-using-iac-20230808-183322-meeting-recording.md
@@ -0,0 +1,52 @@
+---
+title: "Learning Sessions ECS Deployment using IAC - 20230808"
+type: source
+tags: [AWS, ECS, IaC, Terraform, CTP]
+date: 2023-08-08
+---
+
+## Source File
+- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/03_Terraform/learning-sessions-ecs-deployment-using-iac-20230808-183322-meeting-recording.md]]
+
+## Summary（用中文描述）
+- 核心主题：通过 IaC（Terraform）实现 ECS（Elastic Container Service）容器化应用的自动化部署，由 JP 和 Raja M 主讲
+- 问题域：企业在云端部署容器化应用时面临的不可预测性、敏捷性需求，以及 ECS 与 EKS/Kubernetes 的选型权衡
+- 方法/机制：CTP/SRE 团队基于 Gruntwork 仓库构建的 Terraform ECS 模块，支持 Docker 容器创建、自动扩缩容、自动故障恢复和金丝雀部署；通过 Listener 方式集中管理 ECS；配置文件支持 YAML/JSON；集成 CloudWatch、Splunk、Grafana、Prometheus
+- 结论/价值：ECS 作为 AWS 原生技术，与 AWS 服务深度集成，适合追求简单性和 AWS 紧密集成的场景；Terraform IaC 模块化封装降低了部署复杂度
+
+## Key Claims（用中文描述）
+- JP 指出行业面临不可预测性和敏捷性挑战，企业必须在这些挑战中生存，而这一切由代码驱动（"Businesses have to thrive in the middle of all these challenges and it is forged by code."）
+- 动态扩缩容对于不可预测的负载模式至关重要，技术必须持续演进以应对
+- ECS (Elastic Container Services) 是 AWS 专有技术，与 AWS 服务深度集成，相比 EKS 或原生 Kubernetes 有其独特优势和挑战
+- CTP/SRE 团队在 Gruntwork 仓库基础上构建了 ECS 模块，将 Docker 容器作为逻辑单元创建，支持 EC2 实例或目标部署
+- ECS 模块实现了 Listener 方式集中管理，因为许多产品团队从 Gruntwork 下载代码后本地使用
+- 使用模块的前置条件包括：VPC、ELB 安全组、EFS 卷挂载
+
+## Key Quotes
+> "Businesses have to thrive in the middle of all these challenges and it is forged by code." — JP，阐述企业如何在云转型挑战中通过代码驱动适应
+> "We have implemented the listener approach because we have seen many of the products are downloading the quotes from the gruntwork and using locally." — Raja M，解释为何 CTP 团队实现 Listener 集中管理方式
+
+## Key Concepts
+- [[Infrastructure-as-Code]]：Terraform IaC 驱动 ECS 部署的核心方法论
+- [[ECS-Module-Deployment]]：CTP/SRE 团队基于 Gruntwork 构建的 ECS 自动化部署模块
+- [[Listener-Approach]]：ECS 集中管理方式，避免各产品团队重复下载使用 Gruntwork 代码
+- [[Canary-Deployment]]：ECS 模块支持的金丝雀部署策略
+
+## Key Entities
+- [[AWS]]：Amazon Web Services，提供 ECS 容器服务及配套生态（CloudWatch、VPC、ELB、EFS）
+- [[Gruntwork]]：IaC 基础设施代码库，CTP 的 ECS 模块基于 Gruntwork 仓库构建
+- [[CTP]]（Cloud Transformation Programme）：云转型计划，每周定期举办 Learning Sessions 学习会议
+- [[JP]]：演讲者之一，讲解 ECS 的业务和技术背景
+- [[Raja-M]]：演讲者之一，详细介绍 CTP 和 SRE 团队开发的 ECS 模块
+
+## Connections
+- [[ctp-topic-70-eks-deployment-using-iac]] ← extends ← [[Infrastructure-as-Code]]（同一 IaC 主题，EKS 与 ECS 两条路径）
+- [[ctp-topic-9-ci-cd-with-gruntwork]] ← builds_on ← [[Gruntwork]]（Gruntwork CI/CD 实践是 ECS 模块的基础）
+- [[ctp-topic-33-an-introduction-to-gitops]] ← related_to ← [[Infrastructure-as-Code]]（GitOps 与 IaC 协同）
+
+## Contradictions
+- 与 [[ctp-topic-64-scaling-out-with-amazon-eks]] 在容器编排选型上的差异：
+ - 冲突点：ECS 与 EKS 哪个更适合企业容器化部署
+ - 当前观点：ECS 作为 AWS 原生技术与 AWS 服务深度集成，适合追求简单性和紧密集成的场景
+ - 对方观点：EKS 提供更强的可移植性和 Kubernetes 生态系统支持，适合需要多云或混合云策略的场景
+ - 注：两者并非互斥，ECS 和 EKS 可根据具体场景互补使用
diff --git a/wiki/sources/public-cloud-learning-sessions-opentext-ai-use-cases-20241126-160106-meeting-rec.md b/wiki/sources/public-cloud-learning-sessions-opentext-ai-use-cases-20241126-160106-meeting-rec.md
new file mode 100644
index 00000000..8ae78180
--- /dev/null
+++ b/wiki/sources/public-cloud-learning-sessions-opentext-ai-use-cases-20241126-160106-meeting-rec.md
@@ -0,0 +1,54 @@
+---
+title: "Public Cloud Learning Sessions (OpenText) - AI Use Cases - 20241126 160106"
+type: source
+tags:
+ - AI
+ - Use-Cases
+ - OpenText
+ - AWS
+ - Generative-AI
+date: 2024-11-26
+---
+
+## Source File
+- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/09_Serverless_AI/public-cloud-learning-sessions-opentext-ai-use-cases-20241126-160106-meeting-rec.md]]
+
+## Summary（用中文描述）
+- 核心主题：AWS AI 专家 Stephen Frank 分享 Gen2 AI（生成式 AI）的发展驱动力、企业级应用场景及 AWS 三层产品战略
+- 问题域：企业软件公司如何利用生成式 AI 实现差异化竞争，AI 数据策略选择（RAG / Fine-tuning / Continued Pre-training）
+- 方法/机制：AWS 三层产品架构（基础设施 → Amazon Bedrock → AI 应用）；Amazon Q 企业知识问答；数据与 AI 模型集成的三种方法
+- 结论/价值：数据是差异化关键；RAG 可在无需重训练的情况下连接自有业务数据；实施 AI 需要培育实验文化、灵活选择模型、重视安全治理与合规
+
+## Key Claims（用中文描述）
+- 自 2000 年代以来数据量爆发式增长，加上算力提升，驱动了 Gen2 AI 的崛起
+- Amazon 在核心产品和服务中应用 AI/ML 已达 25 年
+- 生成式 AI 应用的差异化关键在于数据——通过 RAG/Fine-tuning/持续预训练与现有业务数据集成
+- AWS 三层产品战略：基础设施层（基础模型训练/推理）→ Amazon Bedrock（旗舰 API 访问）→ 即用型 AI 应用
+- Amazon Bedrock 确保用户数据与提示词不与第三方模型提供商共享，符合 GDPR 合规要求
+- 负责任 AI 的核心原则：公平性（Fairness）、可解释性（Explainability）、透明度（Transparency）
+
+## Key Quotes
+> "Data is key to differentiation, as generative AI applications integrate with existing business data to control outcomes." — Stephen Frank, AWS AI Specialist
+> "When implementing your services, we do have to look at this more holistically." — Stephen Frank, AWS AI Specialist
+
+## Key Concepts
+- [[RAG]]：将生成式 AI 应用与企业现有业务数据集成，无需重训练即可控制输出结果
+- [[Fine-Tuning]]：通过领域数据微调基础模型，提升特定任务表现
+- [[Continued-Pre-Training]]：持续预训练，在基础模型上继续训练以扩展知识
+- [[Responsible-AI]]：公平性、可解释性、透明度的 AI 实施原则
+
+## Key Entities
+- [[AWS]]：亚马逊云科技，提供三层 AI 产品战略
+- [[Amazon-Bedrock]]：AWS 旗舰生成式 AI 服务，提供 API 访问多种基础模型（Anthropic/Titan 等），保证数据不与第三方共享
+- [[Amazon-SageMaker]]：AWS 全托管机器学习平台，面向数据科学家和平台工程师
+- [[Amazon-Q]]：AWS 预构建 AI 系统，支持知识摘要、内容创建和洞察提取，自然语言连接多种数据源
+- [[Stephen-Frank]]：AWS AI 专家，主讲本次会议
+
+## Connections
+- [[public-cloud-learning-sessions-introduction-to-artificial-intelligence-ai-machin]] ← extends ← [[public-cloud-learning-sessions-opentext-generative-ai-prompt-engineering-2024111]]
+- [[Amazon-Bedrock]] ← is part of ← [[AWS]] AI 三层产品战略
+- [[Amazon-Q]] ← is part of ← [[AWS]] AI 三层产品战略
+- [[RAG]] ← depends_on ← [[Fine-Tuning]]
+
+## Contradictions
+- 无明显内容冲突。本来源与 [[public-cloud-learning-sessions-introduction-to-artificial-intelligence-ai-machin]] 和 [[public-cloud-learning-sessions-opentext-generative-ai-prompt-engineering-2024111]] 共同构成 Serverless & AI 知识链路，内容互补而非冲突。
diff --git a/wiki/sources/public-cloud-learning-sessions-opentext-event-driven-architecture-part-1-2024091.md b/wiki/sources/public-cloud-learning-sessions-opentext-event-driven-architecture-part-1-2024091.md
new file mode 100644
index 00000000..8cf4d2cb
--- /dev/null
+++ b/wiki/sources/public-cloud-learning-sessions-opentext-event-driven-architecture-part-1-2024091.md
@@ -0,0 +1,51 @@
+---
+title: "Public Cloud Learning Sessions (OpenText) - Event Driven Architecture Part 1"
+type: source
+tags:
+ - EDA
+ - Event-Driven
+ - AWS
+ - Architecture
+ - OpenText
+date: 2024-09-17
+last_updated: 2026-05-05
+---
+
+## Source File
+- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/09_Serverless_AI/public-cloud-learning-sessions-opentext-event-driven-architecture-part-1-2024091]]
+
+## Summary（用中文描述）
+- 核心主题：事件驱动架构（Event-Driven Architecture，EDA）入门与概述
+- 问题域：企业级云架构中的异步通信与松耦合集成设计
+- 方法/机制：主讲人 Dr. Anil Giri（AWS 解决方案架构师）介绍通过 Amazon EventBridge、SQS 和 SNS 探索事件驱动架构；会议录音包含开场介绍与主持人协调过程（演示过程中遭遇 Teams 屏幕共享技术故障）
+- 结论/价值：帮助参与者掌握企业级集成模式（Enterprise Integration Patterns），学习实用的云计算技能，为解决现实世界业务挑战打下基础
+
+## Key Claims（用中文描述）
+- Amazon EventBridge、SQS 和 SNS 是实现事件驱动架构的核心 AWS 服务
+- 事件驱动架构能够帮助企业实现松耦合、可扩展的系统集成
+- 企业级集成模式（Enterprise Integration Patterns）是构建可靠分布式系统的理论基础
+
+## Key Quotes
+> "探索企业级集成模式，掌握实用的云计算技能，通过使用 Amazon EventBridge、SQS 和 SNS 探索事件驱动架构，以解决现实世界中的业务挑战。" — Dr. Anil Giri，AWS 解决方案架构师，开场学习目标介绍
+
+> "Give me a second. I'm trying to log in. Just give me a second." — 会议期间 Teams 屏幕共享故障场景
+
+## Key Concepts
+- [[Event-Driven-Architecture]]：一种软件架构范式，其中组件通过事件的产生、消费和响应进行通信，强调松耦合
+- [[Enterprise-Integration-Patterns]]：企业集成模式，是构建可靠分布式系统时常见问题的可复用解决方案集合
+- [[Amazon-EventBridge]]：AWS 无服务器事件总线服务，用于连接应用程序与来自各种来源的事件
+- [[Amazon-SQS]]：AWS 简单队列服务，提供完全托管的消息队列服务
+- [[Amazon-SNS]]：AWS 简单通知服务，提供发布/订阅式的消息通知服务
+
+## Key Entities
+- [[Dr.-Anil-Giri]]：AWS 解决方案架构师，Event Driven Architecture 系列主讲人
+- [[AWS]]：Amazon Web Services，云服务提供商，EventBridge/SQS/SNS 的托管方
+- [[OpenText]]：会议主办方，Public Cloud Learning Sessions 系列活动的组织者
+- [[Micro-Focus]]：原公司名称，现已被 OpenText 收购，学习会话的参与群体来源
+
+## Connections
+- [[public-cloud-learning-sessions-opentext-event-driven-architecture-part-2-2024091]] ← part_of ← [[public-cloud-learning-sessions-opentext-event-driven-architecture-part-1-2024091]]（Part 1 与 Part 2 为同一系列，Part 2 包含具体演示内容）
+- [[public-cloud-learning-sessions-opentext-serverless-computing-20240903-160139-mee]] ← related_to ← [[Event-Driven-Architecture]]（Serverless 与 EDA 高度相关，Serverless 计算天然适合事件驱动场景）
+
+## Contradictions
+- 与 [[ctp-topic-64-scaling-out-with-amazon-eks]] 在扩展方式上的差异——EDA 通过事件驱动异步扩展，EKS 通过容器编排横向扩展，两者适用于不同场景但可互补使用
diff --git a/wiki/sources/public-cloud-learning-sessions-opentext-event-driven-architecture-part-2-2024091.md b/wiki/sources/public-cloud-learning-sessions-opentext-event-driven-architecture-part-2-2024091.md
new file mode 100644
index 00000000..bd96c3de
--- /dev/null
+++ b/wiki/sources/public-cloud-learning-sessions-opentext-event-driven-architecture-part-2-2024091.md
@@ -0,0 +1,62 @@
+---
+title: "Public Cloud Learning Sessions (OpenText) - Event Driven Architecture Part 2"
+type: source
+tags:
+ - EDA
+ - Event-Driven
+ - Architecture
+ - OpenText
+date: 2024-09-17
+last_updated: 2026-05-05
+---
+
+## Source File
+- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/09_Serverless_AI/public-cloud-learning-sessions-opentext-event-driven-architecture-part-2-2024091]]
+
+## Summary（用中文描述）
+- 核心主题：事件驱动架构（EDA）进阶实践——最佳实践、团队独立性、常见消息模式
+- 问题域：如何在企业云环境中设计、落地和治理事件驱动架构
+- 方法/机制：Dr. Anil Giri（AWS 解决方案架构师）详解 EDA 三组件（事件生产者/消费者/代理）、事件路由器（EventBridge/SNS）与事件存储（SQS/Kinesis）、编排与编排模式（Choreography vs Orchestration）、幂等性、事件排序、团队去中心化所有权
+- 结论/价值：帮助团队掌握 EDA 生产级最佳实践，在保证弹性和可扩展性的同时实现团队独立自治
+
+## Key Claims（用中文描述）
+- 事件代理分两类：事件路由器（EventBridge/SNS，按规则过滤路由）和事件存储（SQS/Kinesis，由消费者自己过滤）
+- EventBridge 比 SNS 功能更丰富，支持跨 AWS 服务的事件触发和工作流编排
+- 幂等性（Idempotency）是处理 EDA 消息重复的关键机制，AWS Lambda 异步调用会自动重试
+- SQS FIFO 和 Kinesis Data Streams 可保证事件顺序；标准 SQS 和 EventBridge 支持乱序处理
+- 团队独立性应采用去中心化所有权，云卓越中心（Cloud CoE）提供基础设防，团队自主消费事件
+- Fan-out 模式通过 SNS 主题或 EventBridge 规则将事件分发到不同团队
+
+## Key Quotes
+> "Event is nothing but it's like a change in the state or an update." — Dr. Anil Giri，EDA 定义
+
+> "Everything fails every time means like whatever you have designed and whatever workload you is running it may fail any time." — 容错设计哲学
+
+## Key Concepts
+- [[Event-Driven-Architecture]]：一种软件架构范式，通过事件的生产、消费和响应实现松耦合通信
+- [[Choreography]]：编排模式的一种，各微服务自主通信，无需中央协调者
+- [[Orchestration]]：编排模式的一种，通过中央协调者（如 AWS Step Functions）控制工作流步骤
+- [[Idempotency]]：幂等性——同一操作执行一次或多次产生相同结果的特性
+- [[Fan-Out-Pattern]]：一对多消息分发模式，通过 SNS 主题或 EventBridge 规则将事件广播给多个消费者
+- [[Competing-Consumer-Pattern]]：竞争消费者模式，同一时间只有一个消费者可处理消息（SQS 实现）
+- [[Dead-Letter-Queue-DLQ]]：死信队列，用于处理失败事件，防止消息丢失
+
+## Key Entities
+- [[AWS]]：Amazon Web Services，EventBridge/SQS/SNS/Lambda/Kinesis/AWS Step Functions 的托管方
+- [[Amazon-EventBridge]]：AWS 事件路由器，支持规则过滤、跨服务触发、Schema 注册
+- [[Amazon-SQS]]：AWS 消息队列服务，分标准队列（乱序/高效）和 FIFO 队列（有序/Exactly-Once）
+- [[Amazon-SNS]]：AWS 发布/订阅通知服务，实现 Fan-out 分发
+- [[AWS-Lambda]]：AWS 无服务器函数，EDA 的核心事件消费者，异步调用自动重试
+- [[AWS-Step-Functions]]：AWS 状态机编排服务，实现 Orchestration 模式
+- [[Kinesis-Data-Streams]]：AWS 流数据服务，支持事件持久化和有序处理
+- [[Dr.-Anil-Giri]]：AWS 解决方案架构师，Event Driven Architecture 系列主讲人
+- [[OpenText]]：会议主办方，Public Cloud Learning Sessions 系列活动的组织者
+
+## Connections
+- [[public-cloud-learning-sessions-opentext-event-driven-architecture-part-1-2024091]] ← part_of ← [[public-cloud-learning-sessions-opentext-event-driven-architecture-part-2-2024091]]（Part 1 与 Part 2 为同一系列，Part 2 补充具体演示内容）
+- [[public-cloud-learning-sessions-opentext-serverless-computing-20240903-160139-mee]] ← related_to ← [[Event-Driven-Architecture]]（Serverless 天然适合事件驱动，Lambda 是 EDA 的核心执行单元）
+- [[Event-Driven-Architecture]] ← depends_on ← [[Amazon-EventBridge]]（EventBridge 是 AWS EDA 的核心事件总线）
+- [[Event-Driven-Architecture]] ← uses ← [[Idempotency]]（幂等性是 EDA 生产级落地的必要保障）
+
+## Contradictions
+- 与 [[ctp-topic-64-scaling-out-with-amazon-eks]] 在扩展方式上的差异——EDA 通过事件驱动异步扩展（消费者按需处理），EKS 通过容器编排横向扩展（Pod 副本数调整），两者适用于不同场景但可互补使用
diff --git a/wiki/sources/public-cloud-learning-sessions-opentext-generative-ai-prompt-engineering-2024111.md b/wiki/sources/public-cloud-learning-sessions-opentext-generative-ai-prompt-engineering-2024111.md
new file mode 100644
index 00000000..ed7ba611
--- /dev/null
+++ b/wiki/sources/public-cloud-learning-sessions-opentext-generative-ai-prompt-engineering-2024111.md
@@ -0,0 +1,66 @@
+---
+title: "Public Cloud Learning Sessions (OpenText) - Generative AI & Prompt Engineering - 20241112"
+type: source
+tags:
+ - Generative-AI
+ - Prompt-Engineering
+ - OpenText
+ - AWS
+date: 2024-11-12
+---
+
+## Source File
+- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/09_Serverless_AI/public-cloud-learning-sessions-opentext-generative-ai-prompt-engineering-2024111.md]]
+
+## Summary（用中文描述）
+- 核心主题：AWS 生成式 AI 服务与提示工程基础，由 OpenText 技术客户经理 Shikad Holtzman 主讲
+- 问题域：企业如何在 AWS 上构建有业务价值的生成式 AI 应用
+- 方法/机制：Amazon Bedrock 全托管基础模型服务、RAG（检索增强生成）、微调、持续预训练、Amazon Q 助手、提示工程技巧
+- 结论/价值：企业数据是差异化关键，通过 Bedrock 连接自有数据，无需重训练即可构建专属生成式 AI 应用；提示工程通过清晰指令、上下文、示例和链式思维可显著提升 LLM 输出质量
+
+## Key Claims（用中文描述）
+- Shikad Holtzman（以色列技术客户经理）通过 AWS 生成式 AI 堆栈三层架构（基础设施/服务/应用）介绍了创新机会与行业通用场景
+- 生成式 AI 通过创造新体验、提升员工生产力、提取洞察、激发创造力四大路径为企业创造价值；应用场景涵盖客服聊天机器人、代码生成摘要、文档处理和图像生成
+- 企业数据是生成式 AI 应用从通用走向专属、产生实际业务价值的关键差异化因素
+- RAG（检索增强生成）是成本最低、最快速的定制化方法，连接多数据源无需重训练模型；微调通过标注示例重训练模型；持续预训练用无标签数据适配特定领域
+- Amazon Bedrock 是全托管服务，提供来自 Anthropic、Meta、Amazon（Titan）的多种基础模型（含多模态和图像模型），并内置 RAG 知识库、微调、Agents 和 Responsible AI 能力，且用户数据和提示不会与模型提供商共享
+- Amazon Bedrock Guardrails 允许用户根据自身策略过滤有害内容
+- Amazon Q 分为企业版（连接多数据源进行搜索/摘要/洞察提取，维持现有权限）和开发者版（专注代码生成、单元测试和代码迁移）
+- 提示工程是创建、设计和优化提示词以引导 LLM 响应的过程，需清晰、准确、具体，遵循迭代测试优化；提示包含指令、上下文、用户输入和输出指示器四部分
+- 少样本提示（One-shot/Few-shot）通过提供示例帮助模型理解任务模式；链式思维（Chain of Thoughts）通过逐步推理引导模型解决复杂任务
+
+## Key Quotes
+> "Your data is your differentiator and it is what makes the difference between generic application to a specific application that can actually bring business to your value." — Shikad Holtzman，强调企业数据是生成式 AI 差异化的核心
+
+> "None of your data nor not the prompts, not the data that you are using for customizing the model is being shared with the model providers." — 强调 Amazon Bedrock 的数据隔离承诺
+
+## Key Concepts
+- [[RAG]]：检索增强生成，通过连接外部数据源，无需重训练即可让基础模型回答特定领域问题，是成本最低的定制化路径
+- [[Prompt-Engineering]]：提示工程，通过设计清晰指令、上下文、示例和输出指示器引导 LLM 生成准确相关响应的技术和迭代过程
+- [[Chain-of-Thought]]：链式思维，一种提示工程技巧，通过让模型展示逐步推理过程来提升复杂任务表现
+- [[One-Shot-Prompting]]：单样本提示，一种提示技巧，通过提供一个示例帮助模型理解任务格式和期望
+- [[Few-Shot-Prompting]]：少样本提示，通过提供多个示例（通常2-5个）让模型从示例中学习模式和规则
+- [[Responsible-AI]]：负责任 AI，Amazon Bedrock 内置的能力，包括内容过滤和道德准则实施
+- [[Guardrails-for-Amazon-Bedrock]]：Bedrock 护栏，允许用户配置自定义策略过滤有害内容的基础安全功能
+
+## Key Entities
+- [[Shikad-Holtzman]]：OpenText 技术客户经理（驻以色列），本次学习会议讲师，专注于 AWS 生成式 AI 应用与创新机会分享
+- [[Amazon-Bedrock]]：AWS 全托管基础模型服务，提供多提供商模型（Anthropic/Amazon Titan/Meta），内置 RAG、微调、Agents 和 Responsible AI 能力
+- [[Amazon-SageMaker]]：AWS 托管服务，覆盖基础模型构建、训练和部署全生命周期；SageMaker JumpStart 提供公开可用基础模型和第三方模型访问
+- [[Amazon-Q]]：AWS AI 助手，分企业版（多数据源连接、搜索摘要）和开发者版（代码生成、单元测试、代码迁移）
+- [[AWS-Trainium]]：AWS 专用训练芯片，用于基础模型训练
+- [[AWS-Inferentia]]：AWS 专用推理芯片，用于模型推理部署
+- [[AWS]]：Amazon Web Services，OpenText Cloud 转型计划的云服务提供商
+
+## Connections
+- [[Amazon-Bedrock]] ← extends ← [[Foundation-Models]]
+- [[RAG]] ← part_of ← [[Amazon-Bedrock]]
+- [[Amazon-Q]] ← part_of ← [[AWS-Generative-AI-Stack]]
+- [[Prompt-Engineering]] ← uses ← [[Chain-of-Thought]]
+- [[Prompt-Engineering]] ← uses ← [[Few-Shot-Prompting]]
+- [[Amazon-SageMaker]] ← part_of ← [[AWS-Generative-AI-Stack]]
+- [[public-cloud-learning-sessions-introduction-to-artificial-intelligence-ai-machin]] ← related ← [[public-cloud-learning-sessions-opentext-generative-ai-prompt-engineering-2024111]]（同属 AWS AI/ML 入门系列）
+- [[public-cloud-learning-sessions-opentext-serverless-computing-20240903-160139-mee]] ← related ← [[public-cloud-learning-sessions-opentext-generative-ai-prompt-engineering-2024111]]（同属 OpenText Serverless & AI 专题）
+
+## Contradictions
+- 与 [[ctp-topic-64-scaling-out-with-amazon-eks]] 在扩展方式上的差异：EDA 通过事件驱动异步扩展，EKS 通过容器编排横向扩展，两者适用于不同场景但可互补使用
diff --git a/wiki/sources/public-cloud-learning-sessions-opentext-serverless-computing-20240903-160139-mee.md b/wiki/sources/public-cloud-learning-sessions-opentext-serverless-computing-20240903-160139-mee.md
new file mode 100644
index 00000000..befa52f4
--- /dev/null
+++ b/wiki/sources/public-cloud-learning-sessions-opentext-serverless-computing-20240903-160139-mee.md
@@ -0,0 +1,62 @@
+---
+title: "Public Cloud Learning Sessions - Serverless Computing - 20240903"
+type: source
+tags:
+ - Serverless
+ - AWS
+ - Lambda
+ - Step-Functions
+ - API-Gateway
+ - OpenText
+date: 2026-04-14
+---
+
+## Source File
+- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/09_Serverless_AI/public-cloud-learning-sessions-opentext-serverless-computing-20240903-160139-mee.md]]
+
+## Summary（用中文描述）
+- 核心主题：AWS 无服务器计算（Serverless Computing），聚焦 AWS Lambda、Step Functions 和 API Gateway
+- 问题域：企业如何在云环境中简化应用管理、降低运维负担、加快上市时间
+- 方法/机制：Lambda 事件驱动函数 → Step Functions 工作流编排 → API Gateway API 管理，AWS 与客户共担运维责任（AWS 管基础设施，客户管代码）
+- 结论/价值：Serverless 模式通过"按需付费、自动扩展、内置安全"实现更快的市场响应和更低的 TCO
+
+## Key Claims（用中文描述）
+- AWS Lambda 将运维任务（负载均衡、自动扩展、安全）转移给云厂商，使开发团队专注业务逻辑
+- Lambda 函数支持同步、异步、事件源映射三种触发模式，可精细控制执行行为
+- Lambda 权限模型分为执行角色（决定函数能做什么）和资源策略（决定谁能触发函数）
+- Step Functions 提供 Standard 和 Express 两种工作流类型，分别适用于长时任务和高频场景
+- SAM（Serverless Application Model）基于 CloudFormation 构建，支持本地开发和测试 Lambda 函数
+- Lambda Layers 允许跨函数共享公共代码，提高复用率；ARM64 架构提供更优性价比
+
+## Key Quotes
+> "Whenever you see that you have written code and you want that this code is final, you can publish as a new version." — Lambda 版本发布的核心理念
+
+## Key Concepts
+- [[Serverless-Computing]]：将运维任务（负载均衡、自动扩展、安全补丁）转移给云厂商，使开发团队专注业务代码，无需管理服务器
+- [[Event-Driven-Architecture]]：Lambda 函数由事件触发——状态的任何变化即为事件，是 Serverless 的核心执行模型
+- [[Lambda-Permissions-Model]]：执行角色（Execution Role）决定函数能调用哪些 AWS 资源，资源策略（Resource-Based Policy）决定谁能触发该函数，两者分离实现最小权限原则
+- [[Step-Functions]]：无服务器工作流编排服务，基于状态机协调多个 AWS 服务，支持 Standard（长时）和 Express（高频）两种工作流类型
+- [[API-Gateway]]：托管式 API 创建、发布和安全服务，提供边缘优化（Edge-Optimized）、区域（Regional）和私有（Private）三种部署选项
+- [[SAM-Serverless-Application-Model]]：基于 CloudFormation 的无服务器应用开发工具，支持本地测试和部署 Lambda 函数
+
+## Key Entities
+- [[AWS Lambda]]：AWS 无服务器计算核心服务，开发者只需提供业务逻辑，AWS 负责其余所有运维工作
+- [[AWS Step Functions]]：AWS 无服务器工作流编排服务，用于协调多个 Lambda 函数和 AWS 服务的执行顺序
+- [[Amazon API Gateway]]：AWS 托管式 API 管理服务，用于创建、发布和维护安全的企业级 API
+- [[Amazon EventBridge]]：AWS 事件总线服务，用于在应用程序之间路由事件（属于 AWS Serverless 服务组合）
+- [[AWS Fargate]]：AWS 无服务器容器计算服务（与 Lambda 互补，提供容器层的 Serverless 选项）
+- [[Amazon Q]]：AWS AI 助手，可用于调试 Lambda 函数（CloudWatch 集成）
+- [[CloudWatch]]：AWS 监控服务，Lambda 将指标（请求数、错误数、延迟、节流）上报至此
+- [[Serverless-Application-Model-SAM]]：AWS 官方开源工具，基于 CloudFormation 简化无服务器应用的本地开发和部署
+
+## Connections
+- [[AWS-Lambda]] ← is_a ← [[Serverless-Computing]]
+- [[AWS-Step-Functions]] ← orchestrates ← [[AWS-Lambda]]
+- [[Amazon-API-Gateway]] ← exposes ← [[AWS-Lambda]]
+- [[Amazon-EventBridge]] ← triggers ← [[AWS-Lambda]]
+- [[SAM-Serverless-Application-Model]] ← builds_on ← [[CloudFormation]]
+- [[CloudWatch]] ← monitors ← [[AWS-Lambda]]
+- [[Serverless-Computing]] ← extends ← [[Cloud-Transformation-Programme]]
+
+## Contradictions
+- 无已知冲突