Sync: add ses and networking notes

2026-04-24 20:38:20 +08:00
parent e4f6f463cb
commit 7903d703b9
12 changed files with 925 additions and 9 deletions
--- a/wiki/concepts/DKIM-Email-Authentication.md
+++ b/wiki/concepts/DKIM-Email-Authentication.md
@@ -0,0 +1,40 @@
+---
+title: "DKIM Email Authentication"
+type: concept
+tags:
+  - Email
+  - Security
+  - AWS
+date: 2026-04-14
+---
+
+## Definition
+
+DKIM（DomainKeys Identified Mail）是一种电子邮件验证标准，通过在邮件头部添加数字签名来验证邮件确实由声称的域名授权发送，防止邮件被篡改和伪造。
+
+## How DKIM Works
+
+1. **域名所有者**在 DNS 中发布 DKIM 公钥
+2. **发送邮件服务器**使用私钥对邮件头和正文生成数字签名
+3. **接收服务器**通过 DNS 查询获取公钥，验证签名有效性
+4. 签名包含在邮件头的 `DKIM-Signature` 字段中
+
+## DKIM in AWS SES
+
+AWS SES 支持 DKIM 验证：
+- SES 自动为域名生成 DKIM 签名密钥
+- 域名所有者需要在 DNS 中添加三条 CNAME 记录
+- 启用 DKIM 后，SES 自动对所有出站邮件进行签名
+
+## Related Concepts
+- [[SPF]]（Sender Policy Framework）：另一种 DNS ベースの邮件验证方法
+- [[DMARC]]（Domain-based Message Authentication, Reporting & Conformance）：综合 SPF 和 DKIM 的邮件验证框架
+- [[Email-Security]]：邮件安全的整体方法论
+
+## DKIM vs SPF vs DMARC
+
+| 机制 | 验证内容 | 实施难度 |
+|------|----------|----------|
+| SPF | 验证发送服务器 IP 是否被域名授权 | 低 |
+| DKIM | 验证邮件内容未被篡改 | 中 |
+| DMARC | 基于 SPF + DKIM 验证 | 中高 |
--- a/wiki/concepts/SES-Sandbox-Mode.md
+++ b/wiki/concepts/SES-Sandbox-Mode.md
@@ -0,0 +1,46 @@
+---
+title: "SES Sandbox Mode"
+type: concept
+tags:
+  - AWS
+  - SES
+  - Email
+  - Security
+date: 2026-04-14
+---
+
+## Definition
+
+SES Sandbox Mode 是 AWS SES（Simple Email Service）的默认限制状态，新注册的 SES 账户在此状态下仅能向经过验证的收件人地址发送少量邮件，无法向外部地址自由发信。
+
+## Sandbox Mode Restrictions
+
+- **仅限验证地址**：只能向已在 SES 中验证过的邮箱地址发送邮件
+- **发送限额低**：默认每日发送限额为 200 封/天
+- **无外部发信能力**：无法向普通外部邮箱地址（gmail.com、outlook.com 等）发送邮件
+- **申请审批制**：需通过 AWS Support 工单申请脱离沙箱
+
+## How to Exit Sandbox Mode
+
+1. 在 SES 控制台确认已完成域名验证（已完成 DKIM 配置）
+2. 提交 AWS Support 工单申请"生产访问权限"
+3. 在工单中说明使用场景和预计发送量
+4. AWS 审批通过后，账户升级至生产模式
+
+## Production Mode Capabilities
+
+脱离 Sandbox Mode 后：
+- 可向任意外部邮箱地址发送邮件
+- 发送限额大幅提升（可申请更高配额）
+- 可用于生产环境邮件发送
+
+## Important Notes
+
+- 即使在生产模式下，仍需遵守 AWS SES 发送策略和最佳实践
+- 建议申请脱离 Sandbox Mode 后，同步配置 DMARC 策略保护域名声誉
+- 持续监控退回率（bounce rate）和投诉率（complaint rate），避免账户被封禁
+
+## Related Concepts
+- [[AWS-SES]]：Amazon Simple Email Service
+- [[DKIM-Email-Authentication]]：邮件域名验证
+- [[Email-Security]]：邮件安全最佳实践
--- a/wiki/concepts/VPC-Endpoint.md
+++ b/wiki/concepts/VPC-Endpoint.md
@@ -0,0 +1,42 @@
+---
+title: "VPC Endpoint"
+type: concept
+tags:
+  - AWS
+  - Networking
+  - Security
+date: 2026-04-14
+---
+
+## Definition
+
+VPC Endpoint 是 AWS 提供的一项功能，允许在 VPC 内部通过私有 IP 地址安全地访问 AWS 服务，而无需经过公网、互联网网关、NAT 设备或 VPN 连接。
+
+## Two Types
+
+### Interface Endpoint
+- 使用 AWS PrivateLink 技术，在 VPC 中作为弹性网络接口（ENI）部署
+- 为 AWS 服务（如 S3、DynamoDB、SES SMTP 等）提供私有连接
+- 支持通过安全组控制访问
+
+### Gateway Endpoint
+- 用于 S3 和 DynamoDB
+- 通过路由表中的目标条目将流量路由到 AWS 服务
+- 免费使用
+
+## Key Use Cases
+
+- **SES SMTP 集成**：在应用 VPC 中配置 VPC Endpoint，使应用程序可以在不访问公网的情况下通过私有连接与 SES SMTP 服务通信
+- **S3 访问**：在私有子网中的 EC2 实例通过 Gateway Endpoint 安全访问 S3，避免流量经公网
+- **Secrets Manager 访问**：通过 Interface Endpoint 安全地访问 Secrets Manager，无需公网连接
+
+## Why Use VPC Endpoints
+
+1. **安全**：流量不经过公网，消除互联网暴露面
+2. **低延迟**：私有 IP 直连，减少网络跳数
+3. **合规**：满足严格的网络隔离和合规要求
+4. **成本**：Gateway Endpoint 免费，Interface Endpoint 费用低于 NAT Gateway
+
+## Related Concepts
+- [[AWS-PrivateLink]]：VPC Endpoint 背后使用的核心技术
+- [[Infrastructure-as-Code]]：Terraform 模块可自动化 VPC Endpoint 的创建
--- a/wiki/index.md
+++ b/wiki/index.md
@@ -4,6 +4,8 @@
 - [Overview](overview.md) — living synthesis

 ## Sources
+- [2026-04-24] [Learning Sessions Cloud Transformation Programme-Deploying RDS via Terraform](sources/learning-sessions-cloud-transformation-programme-deploying-rds-via-terraform.md)
+- [2026-04-24] [Learning Sessions Cloud Transformation Programme-20230808 183322-Meeting Recording](sources/learning-sessions-cloud-transformation-programme-20230808-183322-meeting-recordi.md)
 - [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)
@@ -411,9 +413,7 @@
 - [2026-04-20] [design-whimsy-injector](sources/design-whimsy-injector.md) — (expected: wiki/sources/design-whimsy-injector.md — source missing)
 - [2026-04-20] [design-ux-architect](sources/design-ux-architect.md) — (expected: wiki/sources/design-ux-architect.md — source missing)
 - [2026-04-20] [contributing_zh-cn](sources/contributing_zh-cn.md) — (expected: wiki/sources/contributing_zh-cn.md — source missing)
- [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-14] [CTP Topic 12 Using SES SMTP service terraform module](sources/ctp-topic-12-using-ses-smtp-service-terraform-module.md) — Micro Focus 团队通过 Terraform 模块自动化部署 AWS SES SMTP 服务以替代本地 SMTP 网关；Christian + Filos 主讲；VPC 端点私有连接 + IAM/Secrets Manager 凭证管理
 - [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)
@@ -902,6 +902,7 @@
 - [DevOps-Maturity](concepts/DevOps-Maturity.md)
 - [DevOpsCulture](concepts/DevOpsCulture.md)
 - [DevSecOps](concepts/DevSecOps.md)
+- [DKIM-Email-Authentication](concepts/DKIM-Email-Authentication.md)
 - [dm-verity](concepts/dm-verity.md)
 - [DNS托管](concepts/DNS托管.md)
 - [Docker-Compose](concepts/Docker-Compose.md)
@@ -1124,6 +1125,7 @@
 - [Secrets-Management](concepts/Secrets-Management.md)
 - [Security-and-Compliance](concepts/Security-and-Compliance.md)
 - [Self-Education](concepts/Self-Education.md)
+- [SES-Sandbox-Mode](concepts/SES-Sandbox-Mode.md)
 - [Self-Healing-Systems](concepts/Self-Healing-Systems.md)
 - [self-hosted-password-manager](concepts/self-hosted-password-manager.md)
 - [Self-Improving-Skill](concepts/Self-Improving-Skill.md)
@@ -1203,6 +1205,7 @@
 - [VMware-Cloud-on-AWS](concepts/VMware-Cloud-on-AWS.md)
 - [Voice-Interface](concepts/Voice-Interface.md)
 - [Voice-Notification-Channel](concepts/Voice-Notification-Channel.md)
+- [VPC-Endpoint](concepts/VPC-Endpoint.md)
 - [Vulnerability-Scanning](concepts/Vulnerability-Scanning.md)
 - [Wake-on-LAN](concepts/Wake-on-LAN.md)
 - [Wayland](concepts/Wayland.md)
--- a/wiki/log.md
+++ b/wiki/log.md
@@ -1,3 +1,13 @@
+## [2026-05-05] ingest | Learning Sessions Cloud Transformation Programme-20230808 183322-Meeting Recording
+- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/03_Terraform/learning-sessions-cloud-transformation-programme-20230808-183322-meeting-recordi.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 linked: [[Infrastructure-as-Code]], [[Canary-Deployment]], [[ECS-Module]]
+- Entities linked: [[Gruntwork]], [[AWS]], [[Cloud-Transformation-Programme]]
+- Source page: wiki/sources/learning-sessions-cloud-transformation-programme-20230808-183322-meeting-recordi.md
+- Notes: index.md 已替换占位符条目；overview.md 已新增同主题 wikilink；JP 和 Raja M 各出现 1 次，不足独立 Entity 建页阈值，以 wikilink 形式记录于 Source page；无实质性内容冲突，ECS vs EKS 选型差异记录于 Contradictions 节
+- Conflicts: 与 [[ctp-topic-64-scaling-out-with-amazon-eks]] 在容器编排选型上的差异——ECS 强调 AWS 原生集成，EKS 强调可移植性，两者适用于不同场景但可互补
+
 ## [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: ✅ 成功摄入
@@ -2594,4 +2604,18 @@
  - 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 容器编排，适用于不同场景可互补）
+  - 冲突检测：与 ctp-topic-64-scaling-out-with-amazon-eks 在扩展方式上的差异已记录于 Source page Contradictions（EDA 事件驱动 vs EKS 容器编排，适用于不同场景可互补）
+
+## [2026-05-06] ingest | Learning Sessions Cloud Transformation Programme-Deploying RDS via Terraform
+- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/03_Terraform/learning-sessions-cloud-transformation-programme-deploying-rds-via-terraform.md
+- Status: ✅ 成功摄入
+- Summary: Greg（DBRE 团队）讲解通过 Terraform/Terragrunt 在 AWS 部署 RDS——IaC 六大优势（速度/灵活性/一致性/灾难恢复/文档/自动化）；代码即文档；grunt work RDS Service 推荐生产使用（预建 KMS 加密 + CloudWatch 告警），SRE 核心模块功能弱于 grunt work；Terragrunt 保持代码整洁、避免变量重复；Day 2 运维通过 GitHub PR + Atlantis 实现；CloudWatch Dashboard + Alarms 监控告警，注意突发性能实例 CPU credits
+- Concepts linked: [[Infrastructure-as-Code]], [[DRY Principle]], [[GitOps]], [[CloudWatch-Alarms]], [[KMS-Encryption]]
+- Entities linked: [[Gruntwork]], [[Atlantis]], [[Terraform]], [[Terragrunt]], [[DBRE]], [[CloudWatch]]
+- Source page: wiki/sources/learning-sessions-cloud-transformation-programme-deploying-rds-via-terraform.md
+- Notes:
+  - index.md 已替换 expected placeholder 条目，补充中文摘要
+  - overview.md 已新增独立段落（置于 CTP Topic 16 后），与 Terragrunt/Terraform/Gruntwork/Atlantis 等相关来源建立知识链路
+  - DBRE/Greg 提及 1 次，不足 Entity 建页阈值，以 wikilink 形式记录于 Source page
+  - CloudWatch/KMS 在 wiki 中已存在关联页面，以 wikilink 形式记录无需新建
+  - 冲突检测：与 ctp-topic-48-terraform-vs-terragrunt 一致（推荐 Terragrunt）；与 ctp-topic-9-ci-cd-with-gruntwork 互补（Gruntwork CI/CD 基础）；与 ctp-topic-16-cross-account-terraform-modules 共享 Terraform 生态，CI/CD 载体不同无冲突
--- a/wiki/overview.md
+++ b/wiki/overview.md
@@ -57,10 +57,14 @@ Cloud Transformation Programme (CTP) materials cover AWS landing zones, EKS, Ter

 **[[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）。
+**（本条新增）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）。同主题另一来源：[[learning-sessions-cloud-transformation-programme-20230808-183322-meeting-recordi]]。

 **[[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]]（实体）共同构成跨账号部署完整链路。

+**Learning Sessions Cloud Transformation Programme-Deploying RDS via Terraform**（2023 年，Greg，DBRE 团队）：Greg 来自 Database Reliability Engineering 团队，倡导通过 Terraform IaC 部署任何规模的 RDS 到 AWS，相比控制台具有速度、灵活性、一致性、灾难恢复、文档和自动化六大优势——**代码即文档**。RDS 部署提供两种模块选择：**裸 RDS module**（基础功能）和 **grunt work RDS Service**（推荐生产使用，预建 KMS 密钥加密和 CloudWatch 告警，SRE 核心模块功能弱于 grunt work）。**Terragrunt**（Terraform 封装器）用于保持代码整洁、避免变量重复声明，贯彻 DRY 原则；Day 2 运维（扩缩容、补丁、大版本升级）通过修改 Terragrunt 文件并提交 GitHub PR，由 Atlantis 自动应用变更。监控通过 CloudWatch Dashboard + Alarms 实现，需注意突发性能实例（burstable instance）的 CPU credits 消耗。属 [[Infrastructure-as-Code]] 在 RDS 数据库场景的实践，与 [[ctp-topic-48-terraform-vs-terragrunt]]（Terragrunt 推荐）和 [[ctp-topic-16-cross-account-terraform-modules]]（跨账号 Terraform 模块）共同构成 Terraform 生态知识链路，与 [[ctp-topic-9-ci-cd-with-gruntwork]]（Gruntwork CI/CD）共享 Gruntwork 模块体系。
+
+**[[ctp-topic-12-using-ses-smtp-service-terraform-module]]**（CTP Topic 12）：Christian Deckelmann 和 Filos Christolakis 主讲，Micro Focus 团队使用 Terraform 模块自动化部署 AWS SES SMTP 服务以替代传统本地 SMTP 网关——随着业务向云端迁移，本地 SMTP 网关（如 smtbmicrofocus.com）已不再高效，SES 是网络安全部门唯一批准的云端邮件发送方案。Terraform 模块封装了 SMTP 终端节点配置，支持现有应用程序通过标准 SMTP 协议集成，无需重构代码适配 SES API；技术实现：在应用 VPC 中配置 VPC 端点实现私有连接（无需公网访问），通过 IAM 用户凭证作为 SMTP 认证信息并存储于 Secrets Manager，自动化完成 DKIM 验证和 Infoblox DNS 记录创建。两个关键手动步骤：① 申请脱离 SES Sandbox Mode（提交工单获取生产访问权限）以提升发送限额并允许向外部地址发信；② 手动更新 DNS TXT 记录以验证域名所有权（Terraform 难以处理多账号共享域名时对同一 TXT 记录值的追加操作）。未来计划：引入收件人地址限制和凭证滚动更新增强安全功能。与 [[ctp-topic-36-sendgrid-as-an-email-service]] 构成云邮件服务双路径——SendGrid 面向新标准，SES 服务现有应用平滑迁移。属 [[Infrastructure-as-Code]] 在邮件服务场景的实践，与 [[VPC-Endpoint]]、[[Secrets-Manager]] 概念关联。
+
 **[[ctp-topic-21-supply-chain-security-in-micro-focus]]**（CTP Topic 21）：

 **[[ctp-topic-24-micro-focus-product-privacy-framework]]**（CTP Topic 24）：Micro Focus 产品隐私框架在云转型中的应用——PSAC（产品安全顾问委员会）与法律顾问合作，将 GDPR/CCPA 等晦涩法律条款翻译为约 110 项低级别技术要求；隐私框架是 STLC（安全开发生命周期）中 13 个安全与隐私轨道之一；通过五类需求（架构类/文档类/法律类/实现类/SAS 运营类）和成熟度模型（0-4 级）评估产品隐私合规状态；通过"蜘蛛图"直观展示产品在安全去标识化、被遗忘权、数据可移植性等 KPI 上的合规现状；最终产出标准化《产品隐私设置文档》，确保客户获得一致的隐私信息参考。属 [[Product Privacy Framework（产品隐私框架）]] 在 [[Micro Focus]] 云转型场景的核心实践，与 [[Micro Focus Security Development Life Cycle (STLC) Overview]]（STLC 整体架构）直接关联。
--- a/wiki/sources/ctp-topic-12-using-ses-smtp-service-terraform-module.md
+++ b/wiki/sources/ctp-topic-12-using-ses-smtp-service-terraform-module.md
@@ -0,0 +1,59 @@
+---
+title: "CTP Topic 12 Using SES SMTP service terraform module"
+type: source
+tags:
+  - AWS
+  - Terraform
+  - SES
+  - Email
+  - CTP
+  - Cloud-Email
+date: 2026-04-14
+---
+
+## Source File
+- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/03_Terraform/ctp-topic-12-using-ses-smtp-service-terraform-module]]
+
+## Summary（用中文描述）
+- 核心主题：Micro Focus 团队使用 Terraform 模块自动化部署 AWS SES SMTP 服务，以替代传统的本地 SMTP 网关。
+- 问题域：随着业务向云端迁移，使用本地 SMTP 网关（如 smtbmicrofocus.com）已不再高效，网络安全部门要求统一使用云端邮件发送方案。
+- 方法/机制：在应用 VPC 中配置 VPC 终端节点以实现私有连接；通过 IAM 用户凭证作为 SMTP 认证信息并存储于 Secrets Manager；Terraform 模块自动化 SMTP 终端节点配置、DKIM 验证和 DNS 记录创建；支持现有应用程序通过标准 SMTP 协议集成，无需重构代码适配 SES API。
+- 结论/价值：SES 是唯一获网络安全部门批准的云端邮件发送方案；Terraform 模块化封装降低了集成复杂度；需注意两个手动步骤（申请脱离 Sandbox Mode 和手动更新 DNS TXT 记录）。
+
+## Key Claims（用中文描述）
+- 在应用 VPC 中配置 VPC 终端节点，使应用可在不访问公网的情况下通过私有节点与 SES SMTP 服务通信。
+- IAM 用户的 Access Key 和 Secret Key 被转换后作为 SMTP 认证的用户名和密码，相关凭证安全存储于 AWS Secrets Manager。
+- Terraform 模块自动化完成 DKIM 验证和 Infoblox DNS 管理系统中域名所有权记录的创建。
+- 手动更新 DNS TXT 记录以验证域名所有权仍是必需步骤，因 Terraform 难以处理多个 AWS 账号共享同一域名时对同一 TXT 记录值的追加操作。
+- 脱离 SES Sandbox Mode（向 AWS 提交工单申请生产访问权限）是启用完整邮件发送能力的必要前提。
+- SES 是 Micro Focus 网络安全部门唯一批准的云端邮件发送方案，替代了原有的本地 SMTP 网关。
+
+## Key Quotes
+> "随着业务向云端迁移，使用本地 SMTP 网关（如 smtbmicrofocus.com）已不再高效，SES 是目前网络安全部门唯一批准的云端邮件发送方案。" — Christian Deckelmann
+
+> "SES Terraform 模块封装了 SMTP 终端节点的配置，方便现有应用程序通过标准的 SMTP 协议进行集成，而无需重构代码以适配 SES API。" — Filos Christolakis
+
+## Key Concepts
+- [[VPC-Endpoint]]：AWS 提供的私有连接服务，允许在 VPC 内部通过私有 IP 地址安全访问 AWS 服务，无需经过公网。
+- [[DKIM-Email-Authentication]]：DomainKeys Identified Mail 的缩写，一种电子邮件验证标准，通过在邮件头部添加数字签名来防止欺诈和确保邮件完整性。
+- [[Secrets-Manager]]：AWS 提供的凭证管理服务，用于安全地存储和检索 SES SMTP 的认证信息。
+- [[SES-Sandbox-Mode]]：AWS SES 的默认限制状态，仅允许向已验证的地址发送少量邮件，需提交工单申请生产访问权限以提升发送限额。
+
+## Key Entities
+- [[AWS]]：Amazon Web Services，云服务提供商，SES（Simple Email Service）所属平台。
+- [[Christian-Deckelmann]]：演讲者之一，分享 Micro Focus 在云转型中采用 SES SMTP 服务的背景与动机。
+- [[Filos-Christolakis]]：演讲者之一，详细讲解 SES Terraform 模块的技术实现方案。
+- [[Infoblox]]：公司内部使用的 DNS 管理系统，用于存放和管理验证域名所有权所需的 DNS 记录。
+- [[VPC-Wrapper-Module]]：SES Terraform 模块所依赖的前置 VPC 配置模块，负责预先配置 SMTP VPC 终端节点。
+
+## Connections
+- [[VPC-Wrapper-Module]] ← depends_on ← [[ctp-topic-12-using-ses-smtp-service-terraform-module]]
+- [[ctp-topic-12-using-ses-smtp-service-terraform-module]] ← extends ← [[AWS]]
+- [[Terraform-And-Terragrunt-Best-Practices]] ← related_to ← [[ctp-topic-12-using-ses-smtp-service-terraform-module]]（Terragrunt Pre-hook/Post-hook 用于处理手动 DNS 验证步骤）
+- [[ctp-topic-36-sendgrid-as-an-email-service]] ← alternative_to ← [[ctp-topic-12-using-ses-smtp-service-terraform-module]]（SendGrid 被选定为新 Landing Zone 标准，SES 用于现有应用迁移）
+
+## Contradictions
+- 与 [[ctp-topic-36-sendgrid-as-an-email-service]] 在邮件服务选型上的差异：
+  - 冲突点：两门课程分别介绍了不同的云邮件服务方案——SendGrid 被选定为标准云端邮件服务，而 SES 则专注于服务现有应用通过 SMTP 协议迁移上云。
+  - 当前观点：SES 通过 Terraform 模块封装现有应用 SMTP 接入路径，实现平滑迁移，无需修改应用代码。
+  - 对方观点：SendGrid 作为新标准云邮件服务，提供更高上限（每封 1,000 收件人 vs SES 每封 50 收件人）、更简单的 API 集成和全球中继节点。
--- a/wiki/sources/learning-sessions-cloud-transformation-programme-20230808-183322-meeting-recordi.md
+++ b/wiki/sources/learning-sessions-cloud-transformation-programme-20230808-183322-meeting-recordi.md
@@ -0,0 +1,55 @@
+---
+title: "Learning Sessions Cloud Transformation Programme-20230808 183322-Meeting Recording"
+type: source
+tags:
+  - Terraform
+  - CTP
+  - IaC
+date: 2023-08-08
+---
+
+## Source File
+- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/03_Terraform/learning-sessions-cloud-transformation-programme-20230808-183322-meeting-recordi]]
+
+## Summary（用中文描述）
+- 核心主题：通过 Terraform IaC 实现 ECS 容器化应用的自动化部署
+- 问题域：企业在不可预测性和敏捷性需求下的基础设施挑战
+- 方法/机制：基于 Gruntwork 仓库构建 ECS Terraform 模块，支持 Docker 容器/EC2 部署，具备自动扩缩容、自动故障恢复、金丝雀部署能力；采用 Listener 集中管理方式
+- 结论/价值：CTP/SRE 团队通过 IaC 实现 ECS 部署标准化，与 AWS 服务深度集成
+
+## Key Claims（用中文描述）
+- 企业必须在不可预测性和敏捷性需求之间找到平衡，基础设施即代码（IaC）是应对这一挑战的关键手段
+- ECS（Elastic Container Service）是 AWS 原生技术，与 AWS 服务深度集成，相比 EKS 或原生 Kubernetes 有其独特优势与挑战
+- CTP/SRE 团队基于 Gruntwork 仓库构建了可复用的 ECS Terraform 模块，支持 Docker 容器作为逻辑单元
+- ECS 模块支持 EC2 实例或目标部署，具备自动扩缩容、自动故障恢复、金丝雀部署功能
+- Listener 集中管理方式避免了各产品直接下载 Gruntwork 模板并本地使用的碎片化问题
+- ECS 部署的前置条件包括 VPC、ELB 安全组和 EFS 卷挂载
+- 模块支持通过 YAML 或 JSON 传递配置，集成 CloudWatch、Splunk、Grafana 和 Prometheus
+
+## Key Quotes
+> "Businesses have to thrive in the middle of all these challenges and it is forged by code." — JP，阐述企业面临的不可预测性挑战与 IaC 的核心价值
+> "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，说明 Listener 集中管理模式的动机
+
+## Key Concepts
+- [[Infrastructure-as-Code]]：通过代码定义和管理基础设施，实现自动化、可重复、可审计的部署流程
+- [[Canary-Deployment]]：金丝雀部署，通过逐步将流量切换到新版本，降低新版本上线的风险
+- [[ECS-Module]]：CTP/SRE 团队基于 Gruntwork 仓库构建的 ECS Terraform 模块
+
+## Key Entities
+- [[JP]]：主讲人之一，介绍 ECS 的业务和技术背景
+- [[Raja-M]]：CTP/SRE 团队成员，详细讲解 ECS 模块的构建方式
+- [[Gruntwork]]：提供 Terraform 模块的基础仓库，CTP 在其基础上构建了 ECS 模块
+- [[AWS]]：云服务提供商，ECS 为 AWS 弹性容器服务
+- [[Cloud-Transformation-Programme]]：云转型计划，组织发起的基础设施现代化计划
+
+## Connections
+- [[learning-sessions-ecs-deployment-using-iac-20230808-183322-meeting-recording]] ← same_topic ← [[learning-sessions-ecs-deployment-using-iac-20230808-183322-meeting-recording]]
+- [[Infrastructure-as-Code]] ← implements ← [[Cloud-Transformation-Programme]]
+- [[ECS-Module]] ← based_on ← [[Gruntwork]]
+
+## Contradictions
+- 与 [[ctp-topic-64-scaling-out-with-amazon-eks]] 在容器编排选型上存在差异：
+  - 冲突点：ECS 强调 AWS 原生集成，EKS 强调可移植性
+  - 当前观点：ECS 与 AWS 服务深度集成，适合追求 AWS 原生体验的场景
+  - 对方观点：EKS 基于原生 Kubernetes，提供更好的跨云可移植性
+  - 结论：两者适用于不同场景，可根据业务需求互补使用
--- a/wiki/sources/learning-sessions-cloud-transformation-programme-deploying-rds-via-terraform.md
+++ b/wiki/sources/learning-sessions-cloud-transformation-programme-deploying-rds-via-terraform.md
@@ -0,0 +1,57 @@
+---
+title: "Learning Sessions Cloud Transformation Programme-Deploying RDS via Terraform"
+type: source
+tags: [Terraform, RDS, IaC, CTP, DevOps, DBRE, AWS]
+date: 2026-04-14
+---
+
+## Source File
+- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/03_Terraform/learning-sessions-cloud-transformation-programme-deploying-rds-via-terraform]]
+
+## Summary（用中文描述）
+- 核心主题：**通过 Terraform 在 AWS 上部署 RDS 数据库**，涵盖 IaC 最佳实践和 Gruntwork RDS 模块的选型对比
+- 问题域：RDS 部署方式的选择（控制台 vs 代码）、模块选型（grunt work 模块 vs SRE 核心模块）、Day 2 运维（扩缩容/补丁/升级）
+- 方法/机制：使用 Terragrunt（Terraform 封装器）管理 RDS 部署，通过 GitHub PR + Atlantis 实现变更自动化；CloudWatch 负责监控告警
+- 结论/价值：IaC 部署任何规模的 RDS 到 AWS 均优于控制台；grunt work RDS Service 相比裸模块提供更完整的企业级功能（KMS 加密、CloudWatch 告警等）；代码即文档
+
+## Key Claims（用中文描述）
+- **IaC 六大大好处**：速度、灵活性、一致性、灾难恢复、文档、自动化。代码即文档
+- **两种 RDS 部署选项**：裸模块 RDS module（基础功能）vs 更完整的 grunt work RDS Service（推荐，预建 KMS 加密和 CloudWatch 告警）
+- **SRE 核心模块功能弱于 grunt work 服务**：建议生产环境使用 grunt work RDS Service
+- **Terragrunt 优于裸 Terraform**：避免变量重复声明，保持代码整洁，贯彻 DRY 原则
+- **Day 2 运维通过 GitHub PR + Atlantis 实现**：扩缩容、补丁、大版本升级均在 Terragrunt 文件中修改，通过 PR 触发 Atlantis 自动应用
+- **监控方案**：CloudWatch Dashboard + Alarms，注意突发性能实例（burstable instance）的 CPU credits 消耗
+
+## Key Quotes
+> "We use Terragrunt, which is basically it's a wrapper around Terraform, and it allows you to keep your code clean and you're not repeating your variables all the time." — Greg, DBRE Team
+> "The code is the documentation." — Greg, 强调 IaC 的文档价值
+
+## Key Concepts
+- [[Infrastructure-as-Code]]：通过代码定义和版本控制基础设施资源，核心优势包括速度、一致性、灾难恢复和自动化
+- [[DRY Principle]]：Terragrunt 通过管理 provider 和 remote_state 块减少跨环境重复声明
+- [[GitOps]]：通过 GitHub PR + Atlantis 实现基础设施变更的自动化审核和应用
+- [[CloudWatch-Alarms]]：RDS 监控与告警机制，包含突发性能实例的 CPU credits 考虑
+- [[KMS-Encryption]]：grunt work RDS Service 内置的 KMS 密钥加密功能
+
+## Key Entities
+- [[Gruntwork]]：提供预建 Terraform 模块（RDS Service 等），建议生产环境使用其 grunt work RDS Service 而非裸模块
+- [[Atlantis]]：Git 驱动的 Terraform 自动化工具，配合 GitHub PR 实现 IaC 变更
+- [[Terraform]]：云厂商无关的 IaC 核心工具
+- [[Terragrunt]]：Terraform 的 DRY 封装层，用于管理 RDS 部署配置
+- [[DBRE]]：Database Reliability Engineering 团队，Greg 来自该团队
+- [[CloudWatch]]：AWS 监控服务，用于 RDS Dashboard 和 Alarms
+
+## Connections
+- [[learning-sessions-cloud-transformation-programme-20230808-183322-meeting-recordi]] ← related ← [[learning-sessions-cloud-transformation-programme-deploying-rds-via-terraform]]（同一 CTP 系列，ECS 部署 + RDS 部署）
+- [[ctp-topic-48-terraform-vs-terragrunt]] ← related ← [[learning-sessions-cloud-transformation-programme-deploying-rds-via-terraform]]（Terragrunt 在两个主题中均有讨论）
+- [[ctp-topic-16-cross-account-terraform-modules]] ← related ← [[learning-sessions-cloud-transformation-programme-deploying-rds-via-terraform]]（IaC 模块化 + Cross-account Terraform）
+- [[ctp-topic-9-ci-cd-with-gruntwork]] ← foundation ← [[learning-sessions-cloud-transformation-programme-deploying-rds-via-terraform]]（Gruntwork CI/CD 基础）
+- [[Terraform]] ← wraps ← [[Terragrunt]]
+- [[Gruntwork]] ← provides ← [[RDS-Module]]（grunt work RDS Service）
+- [[Atlantis]] ← automates ← [[Terraform]]
+- [[CloudWatch]] ← monitors ← [[RDS-Module]]
+
+## Contradictions
+- 与 [[ctp-topic-9-ci-cd-with-gruntwork]]（Gruntwork CI/CD）：两者均依赖 Gruntwork 模块体系；本主题聚焦 RDS 部署，CI/CD 主题聚焦 ECS 应用部署；RDS 部署同样适用 Gruntwork 流水线规范，两者互补而非冲突
+- 与 [[ctp-topic-48-terraform-vs-terragrunt]]（Terraform vs Terragrunt）：本主题的实际案例印证了该主题的观点——Terragrunt 保持代码整洁、避免变量重复；两主题一致，共同推荐 Terragrunt 作为 Terraform 的封装层
+- 与 [[ctp-topic-16-cross-account-terraform-modules]]（跨账号 Terraform 模块）：两者均讨论 Terraform 模块的运维方式；跨账号模块方案（Jenkins + ECS Deploy Runner）与本主题（RDS 通过 Atlantis）的 CI/CD 载体不同，适用于不同规模和架构场景，无直接冲突