Auto-sync: 2026-04-19 00:02
This commit is contained in:
@@ -2,8 +2,9 @@
|
||||
title: "RTO vs RPO: Key Differences for Modern Disaster Recovery"
|
||||
type: source
|
||||
tags: [灾难恢复, 业务连续性, 持续交付, 特性管理]
|
||||
date: 2019-01-18
|
||||
sources: ["https://launchdarkly.com/blog/rto-vs-rpo/"]
|
||||
last_updated: 2025-07-26
|
||||
last_updated: 2026-04-18
|
||||
---
|
||||
|
||||
## Source File
|
||||
|
||||
@@ -0,0 +1,58 @@
|
||||
---
|
||||
id: ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security
|
||||
title: "CTP Topic 10 AWS Landing Zone (LZ) Data Collection, Tagging Related Security"
|
||||
type: source
|
||||
tags:
|
||||
- AWS
|
||||
- Landing-Zone
|
||||
- Tagging
|
||||
- Security
|
||||
- CTP
|
||||
date: 2026-04-14
|
||||
sources:
|
||||
- NAS /volume2/work/Public Cloud Learning Sessions/CTP _ Topic 10_ AWS Landing Zone (LZ) Data Collection, Tagging _ Related Security.mp4
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题:AWS Landing Zone 部署流程、数据收集策略、基于标签的安全控制机制
|
||||
- 问题域:传统网络安全向云原生安全的转型
|
||||
- 方法/机制:Landing Zone 规划与自动化、基于标签的安全策略、Checkpoint 防火墙的有序层逻辑
|
||||
- 结论/价值:利用标签和 SCP 强制执行标签合规性,实现精细化的流量过滤和隔离
|
||||
|
||||
## Key Claims
|
||||
- Landing Zone 部署前必须深入了解业务部门(BU)的资产清单、IP 地址空间及数据敏感性
|
||||
- 基于标签的安全控制机制可替代传统基于 IP 的防火墙规则
|
||||
- 通过 OU(组织单元)和 SCP(服务控制策略)可防止用户篡改标签绕过安全审计
|
||||
- Checkpoint 防火墙通过有序层逻辑实现地理屏蔽、BU 隔离、产品隔离及环境隔离
|
||||
|
||||
## Key Quotes
|
||||
> "DNS、Transit Gateway 等基础服务的创建已通过 SRE 团队实现了高度自动化" — Steve Jarman
|
||||
> "通过 SCP 的'显式拒绝'逻辑,系统能够强制执行标签规范,确保资源在创建时即具备正确的归属" — 视频内容
|
||||
|
||||
## Key Concepts
|
||||
- [[AWS Landing Zones]]:能够按照最佳实践快速设置、安全且多账号的 AWS 环境的基础架构框架
|
||||
- [[Tagging Methodology]]:标签方法论,通过为资源定义标准化的元数据(如 Owner, BU, Product, Environment),作为自动化管理和安全策略执行的基础
|
||||
- [[Service Control Policies]]:服务控制策略,用于管理组织中的权限,强制执行标签合规性
|
||||
- [[Organizational Unit]]:组织单元,AWS Organizations 中账号的分组容器
|
||||
- [[Checkpoint Firewall]]:部署在云环境中的虚拟防火墙,通过集成 AWS 标签实现动态的对象识别和流量过滤
|
||||
- [[Transit Gateway]]:传输网关,作为网络中心枢纽,连接 VPC 与本地网络
|
||||
- [[Ordered Layer]]:有序层,防火墙策略的一种组织方式,按顺序执行地理屏蔽、BU 隔离、环境隔离等逻辑
|
||||
- [[SRE]]:站点可靠性工程,负责 Landing Zone 部署中的自动化脚本编写与基础架构维护
|
||||
|
||||
## Key Entities
|
||||
- [[AWS]]:全球最大公有云平台
|
||||
- [[Gruntwork]]:Gruntwork Landing Zones 框架提供商
|
||||
|
||||
## Connections
|
||||
- [[CTP Topic 1 Gruntwork Landing Zone Architecture]] ← depends_on ← [[CTP Topic 10 AWS Landing Zone (LZ) Data Collection, Tagging Related Security]]
|
||||
- [[CTP Topic 28 AWS Tag Validation Tool]] ← extends ← [[Tagging Methodology]]
|
||||
- [[CTP Topic 17 Active Directory Services in Gruntwork AWS LZs]] ← depends_on ← [[AWS Landing Zones]]
|
||||
|
||||
## Contradictions
|
||||
- 与传统基于 IP 的防火墙方案冲突:
|
||||
- 冲突点:网络边界防护模式
|
||||
- 当前观点:基于标签的动态安全控制
|
||||
- 对方观点:基于 IP 的静态防火墙规则
|
||||
57
wiki/sources/ctp-topic-22-global-dns-service-offerings.md
Normal file
57
wiki/sources/ctp-topic-22-global-dns-service-offerings.md
Normal file
@@ -0,0 +1,57 @@
|
||||
---
|
||||
title: "CTP Topic 22 Global DNS service offerings"
|
||||
type: source
|
||||
tags:
|
||||
- DNS
|
||||
- Networking
|
||||
- AWS
|
||||
- CTP
|
||||
date: 2026-04-14
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/08_Networking/ctp-topic-22-global-dns-service-offerings.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题:企业在全球范围内的 DNS 服务架构与配置方案
|
||||
- 问题域:AWS 云环境与本地数据中心的混合云 DNS 设计
|
||||
- 方法/机制:Route 53 Private Hosted Zones、Route 53 Resolver Endpoints(入站/出站)、Infoblox DNS Anycast
|
||||
- 结论/价值:实现跨区域和混合云的域名解析高可用性,采用"就近解析"优化 Office 365 等全球化服务访问性能
|
||||
|
||||
## Key Claims
|
||||
- Route 53 Private Hosted Zones 是 AWS 环境的核心 DNS 服务
|
||||
- Route 53 Resolver 出站规则中配置多个区域的 AD 域控制器 IP 可确保 DNS 解析弹性
|
||||
- Infoblox 平台利用 DNS Anycast 技术实现全球低延迟和自动故障转移
|
||||
- AWS EC2 不原生支持 DNS Anycast,需手动维护 IP 列表
|
||||
|
||||
## Key Quotes
|
||||
> "公司正在进行的云转型计划,旨在构建一个高可用、多区域的 Landing Zone 基础架构"
|
||||
|
||||
> "通过在出站规则中配置多个区域的 AD 域控制器 IP,确保即使在某个区域发生故障时,DNS 解析仍能保持弹性"
|
||||
|
||||
> "本地环境采用了 Infoblox 平台,利用 DNS Anycast 技术实现了全球范围内的低延迟和自动故障转移,而 AWS 目前在 EC2 基础架构上尚不支持 Anycast"
|
||||
|
||||
## Key Concepts
|
||||
- [[Route-53-Private-Hosted-Zone]]:AWS 提供的私有托管区域,仅对指定的 VPC 可见
|
||||
- [[Route-53-Resolver-Endpoint]]:入站和出站终端节点,用于 AWS VPC 与本地网络或其他云环境之间转发 DNS 查询
|
||||
- [[DNS-Anycast]]:一种网络寻址和路由方法,使多个 DNS 服务器共享同一个 IP 地址
|
||||
- [[IPAM]]:IP 地址管理工具(如 Infoblox)
|
||||
- [[Landing-Zone]]:预配置好的多账号 AWS 环境
|
||||
- [[Hybrid-DNS-Resolution]]:混合云 DNS 解析机制
|
||||
|
||||
## Key Entities
|
||||
- [[AWS]]:Amazon Web Services,云服务提供商
|
||||
- [[Route-53]]:AWS 的 DNS 服务
|
||||
- [[Active-Directory]]:Microsoft 目录服务
|
||||
- [[Infoblox]]:DNS/DHCP 设备提供商
|
||||
|
||||
## Connections
|
||||
- [[Route-53]] ← manages ← [[Route-53-Private-Hosted-Zone]]
|
||||
- [[Route-53-Resolver-Endpoint]] ← depends_on ← [[Active-Directory]]
|
||||
- [[Hybrid-DNS-Resolution]] ← uses ← [[Route-53-Resolver-Endpoint]]
|
||||
- [[Infoblox]] ← provides ← [[DNS-Anycast]]
|
||||
|
||||
## Contradictions
|
||||
- Infoblox Anycast:本地环境自动实现全球低延迟
|
||||
- Infoblox 方案:自动故障转移,无需手动维护
|
||||
- 当前 AWS 方案:EC2 不支持 Anycast,需手动维护 IP 列表
|
||||
@@ -0,0 +1,61 @@
|
||||
---
|
||||
title: "CTP Topic 25 Labs Landing Zone overview - ITOM teams"
|
||||
type: source
|
||||
tags:
|
||||
- AWS
|
||||
- Landing-Zone
|
||||
- Labs
|
||||
- ITOM
|
||||
- CTP
|
||||
category: DevOps & SRE/01_AWS-Landing-Zone
|
||||
date-added: 2026-04-18
|
||||
sources:
|
||||
- raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-25-labs-landing-zone-overview-itom-teams.md
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-25-labs-landing-zone-overview-itom-teams.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题:Labs Landing Zone 架构概述,基于 Gruntwork reference architecture 和 AWS 标准,采用多账号策略
|
||||
- 问题域:企业级 AWS 云基础设施规划与部署
|
||||
- 方法/机制:IaC(Terraform)管理、标签驱动防火墙策略、CI/CD 自动化(Jenkins + Terragrunt)
|
||||
- 结论/价值:Labs Landing Zone 提供标准化的多账号基础设施框架,通过代码实现一致性、版本控制和自动化治理
|
||||
|
||||
## Key Claims
|
||||
- Labs Landing Zone 基于 Gruntwork reference architecture 和 AWS 标准构建
|
||||
- 整个技术栈通过 Terraform 管理,所有资源必须使用代码机制部署
|
||||
- Shared Account 托管 Jenkins 主服务器、hardened AMIs 和 Docker 容器存储
|
||||
- Logs Account 安全存储 AWS Config 和 CloudTrail 日志,访问权限由安全团队控制
|
||||
- Security Account 管理用户账户和跨账户访问,采用联合身份认证
|
||||
- Active Directory 账户管理 Windows 实例和 IDPs(使用 swimford.net 域名)
|
||||
- DNS 账户管理 AWS Swimford.net,允许本地域或引用更广泛的基础设施
|
||||
- Network Account 是网络通信中心,通过 Transit Gateway 和 JetPult 防火墙管理流量
|
||||
- 所有互联网访问通过该账户路由,通过标签由网络团队管理
|
||||
- Shared Service Accounts 提供监控服务(如 45 arc site)和 Qualys 安全服务
|
||||
- Product Account 是主要工作环境,使用标准化 IaC 模块构建,可包含多个账户(production、staging、development)
|
||||
- 部署 Product Account 时需定义 IP 地址范围,并与网络团队协商防火墙访问的标签
|
||||
- Jenkins 流水线持续扫描 GitHub Enterprise 仓库,根据分支运行 Terragrunt plan 或 apply
|
||||
- 互联网连接受限,访问特定企业网络位置需向网络服务团队申请
|
||||
|
||||
## Key Concepts
|
||||
- [[Gruntwork Landing Zone]]:Gruntwork 提供的预配置 AWS 基础架构框架
|
||||
- [[Multi-Account Strategy]]:AWS 推荐的多账号策略,通过分离工作负载提升安全性和治理能力
|
||||
- [[Infrastructure as Code]]:通过代码实现基础设施管理,确保一致性和版本控制
|
||||
- [[Terraform]]:HashiCorp 开发的 IaC 工具,用于声明式定义云资源
|
||||
- [[Transit Gateway]]:AWS 中心网络路由服务,连接 VPCs 和本地网络
|
||||
- [[Service Control Policies]]:AWS Organizations 的策略类型,管理组织内账户的最大权限边界
|
||||
|
||||
## Key Entities
|
||||
- [[Gruntwork]]:Landing Zone 框架提供商
|
||||
- [[Jenkins]]:开源自动化服务器,用于 CI/CD 流水线
|
||||
- [[swinford.net]]:R&D Labs 环境的 Active Directory 域名
|
||||
|
||||
## Connections
|
||||
- [[Gruntwork Landing Zone]] ← builds_on ← [[AWS Organizations]]
|
||||
- [[Product Account]] ← deploys_via ← [[Terraform]]
|
||||
- [[Network Account]] ← manages ← [[Transit Gateway]]
|
||||
- [[Logs Account]] ← stores ← [[CloudTrail]]
|
||||
|
||||
## Contradictions
|
||||
- (暂无)
|
||||
@@ -0,0 +1,52 @@
|
||||
---
|
||||
title: "CTP Topic 26 Standard AMI – build, publish, share processes"
|
||||
type: source
|
||||
tags: [AWS, AMI, Build-Process, CTP, Cloud-Learning]
|
||||
date: 2026-04-14
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-26-standard-ami-build-publish-share-processes.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题:Foundation AMI(基础亚马逊机器镜像)的构建、加固与分发流程
|
||||
- 问题域:企业级 AWS 镜像标准化与安全合规
|
||||
- 方法/机制:HashiCorp Packer + Jenkins 自动化构建流水线,AMI Sharing 跨账号共享机制
|
||||
- 结论/价值:通过标准化 Foundation AMI 实现"即插即用",确保所有实例从启动之日起符合安全合规标准
|
||||
|
||||
## Key Claims
|
||||
- Foundation AMI 是基于市场主流操作系统(CentOS, Ubuntu, Windows 等)进行深度加固的镜像
|
||||
- Foundation AMI 集成 CIS 安全基准、防病毒软件(McAfee EPO)、日志管理(Syslog-ng)及单点登录(AD 集成)
|
||||
- 镜像通过跨账号共享(Sharing)而非物理复制(Copying)的方式分发到全球多个区域
|
||||
- 镜像每两个月更新一次,遵循 N-2 的版本保留策略
|
||||
|
||||
## Key Quotes
|
||||
> "Foundation AMI 的主要优势在于'即插即用',确保所有实例从启动之日起就符合 Micro Focus 的安全合规标准,并预装了 SSM Agent 和 SiteScope 监控预选件" — Srihari, Alan, Praveen
|
||||
|
||||
## Key Concepts
|
||||
- [[Foundation AMI]]:经过安全加固、集成标准组件并预配置好的操作系统模板
|
||||
- [[OS Hardening]]:操作系统加固,通过关闭不必要服务、优化内核参数和应用安全补丁来减少系统攻击面
|
||||
- [[CIS Benchmarks]]:互联网安全中心制定的安全配置基准
|
||||
- [[HashiCorp Packer]]:开源机器镜像自动化构建工具
|
||||
- [[SSM Agent]]:AWS 系统管理器代理,用于实现实例的远程管理
|
||||
- [[AMI Sharing]]:镜像共享机制,通过授权其他账号访问中央镜像
|
||||
- [[N-2 Version Policy]]:保留最近两个版本的政策
|
||||
|
||||
## Key Entities
|
||||
- [[Standard AMI]]:AWS 标准机器镜像,由 CCOE 维护
|
||||
- [[AWS]]:亚马逊公有云平台
|
||||
- [[Jenkins]]:开源自动化服务器,用于 CI/CD
|
||||
- [[CCOE]]:Cloud Center of Excellence,负责提供安全的基础镜像
|
||||
|
||||
## Connections
|
||||
- [[Standard AMI]] ← provides ← [[Foundation AMI]]
|
||||
- [[Jenkins]] ← builds ← [[HashiCorp Packer]]
|
||||
- [[CCOE]] ← maintains ← [[Standard AMI]]
|
||||
- [[EC2 Image Builder]] ← related_to ← [[Standard AMI]]
|
||||
|
||||
## Contradictions
|
||||
- (暂无)
|
||||
|
||||
## Related Sources
|
||||
- [[Learning Sessions Standard AMIs Updates 20231205]] — AWS Standard AMIs 概述、更新和发布流程
|
||||
- [[CTP Topic 58 AWS EC2 Image Builder]] — AWS EC2 Image Builder 服务详解
|
||||
@@ -0,0 +1,50 @@
|
||||
---
|
||||
title: CTP Topic 34 Azure Landing Zone Architecture Overview
|
||||
type: source
|
||||
tags: [Azure, Landing-Zone, CTP]
|
||||
date: 2026-04-14
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-34-azure-landing-zone-architecture-overview.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题:Azure Landing Zone 在 Micro Focus 的架构设计与实现
|
||||
- 问题域:云采用框架、订阅组织、访问管理
|
||||
- 方法/机制:Management Groups、Subscription 分离、Terraform Cloud 自动化、PIM 权限管理
|
||||
- 结论/价值:通过模块化、自动化的 Landing Zone 设计,各团队可独立部署工作负载,最小化跨团队依赖
|
||||
|
||||
## Key Claims
|
||||
- Azure Landing Zone 通过Management Groups 将组织划分为四个区域:Platform(平台)、Landing Zones(着陆区)、Decommission(退役)、Sandbox(沙盒)
|
||||
- Platform 包含 Identity Management(身份管理)和 Connectivity(连接)两个订阅,分别由专门团队管理,增强安全性
|
||||
- Connectivity 订阅作为所有入站和出站 Azure 流量的中心hub,集成 DDoS 防护和 Checkpoint 防火墙
|
||||
- Landing Zones 设计为可扩展、模块化、完全自动化的模板,为新项目提供标准化基础
|
||||
- Terraform Cloud 使用 Terraform States 管理订阅间的依赖关系,实现分层访问控制
|
||||
|
||||
## Key Quotes
|
||||
> "The core reason of these individual or isolated subscriptions is you are basically containing a subscription for a specific purpose." — 核心设计理念:每个订阅专注于特定用途,实现隔离和管控
|
||||
|
||||
> "This sandbox is an interesting one because these landings on subscriptions allows your workloads." — Sandbox 订阅为实验工作负载提供隔离环境
|
||||
|
||||
## Key Concepts
|
||||
- [[Management Groups]]:Azure 组织管理结构,类似于 Windows 父目录,用于组织订阅
|
||||
- [[Subscription]]:Azure 订阅,隔离的资源容器,每个订阅有特定用途
|
||||
- [[Terraform Cloud]]:HashiCorp 的云基础设施自动化平台,管理 IaC 状态和执行
|
||||
- [[PIM(Privileged Identity Management)]]:Azure 特权身份管理,控制提升权限的访问
|
||||
- [[Azure Landing Zone]]:云采用的起点架构,为工作负载提供安全的标准化基础
|
||||
|
||||
## Key Entities
|
||||
- [[Micro Focus]]:案例公司,正在实施 Azure Landing Zone
|
||||
- [[Kishore Garlopati]]:讲师,介绍 Azure Landing Zone 架构
|
||||
- [[Azure]]:Microsoft 公有云平台
|
||||
- [[Azure Active Directory]]:Azure 身份识别服务,用于用户认证
|
||||
- [[Checkpoint Firewall]]:企业级防火墙解决方案
|
||||
|
||||
## Connections
|
||||
- [[Azure]] ← hosts ← [[Azure Landing Zone]]
|
||||
- [[Azure Landing Zone]] ← uses ← [[Management Groups]]
|
||||
- [[Azure Landing Zone]] ← automates ← [[Terraform Cloud]]
|
||||
- [[Azure Active Directory]] ← authenticates ← [[PIM]]
|
||||
|
||||
## Contradictions
|
||||
- (暂无)
|
||||
@@ -0,0 +1,44 @@
|
||||
---
|
||||
title: "CTP Topic 35 AWS Landing Zone Design Refresher (SaaS Labs)"
|
||||
type: source
|
||||
tags: [AWS, Landing-Zone, SaaS, Labs, CTP]
|
||||
date: 2026-04-14
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-35-aws-landing-zone-design-refresher-saas-labs.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题:AWS Landing Zone 设计更新,区分 SaaS(生产)和 Labs(开发)环境
|
||||
- 问题域:企业级多账号 AWS 架构设计、基础设施即代码
|
||||
- 方法/机制:基于 Gruntwork Terraform 模板的基础设施即代码(IaC)部署
|
||||
- 结论/价值:明确 SaaS 用于生产、Labs 用于开发的定位,统一云交付标准
|
||||
|
||||
## Key Claims
|
||||
- Landing Zone 的核心目标是支持多样化的 AWS 用例,同时确保复用、控制、审计和管理
|
||||
- AWS SaaS landing zones 提供客户专用环境,产品账户连接共享服务账户进行安全、日志和网络管理
|
||||
- Gruntwork 账户管理 AMIs、日志和跨账户安全
|
||||
- 近期更新包括网络分段阻止直接连接到 SaaS 工作负载,停用 Gruntworks CloudTrail,改为 CCOE CloudTrail
|
||||
|
||||
## Key Quotes
|
||||
> "Our AWS landing zones, they're built infrastructure as code as you'd expect on terraform templates using the grunt work framework." — 基础设施即代码实现方式
|
||||
> "Basically, the only answer is that SAS is production, Labs is development." — SaaS 与 Labs 的核心区别
|
||||
|
||||
## Key Concepts
|
||||
- [[Gruntwork Landing Zone]]:Gruntwork 提供的预配置 AWS 基础架构框架
|
||||
- [[Multi-Account Strategy]]:AWS 多账号架构策略,分离工作负载提升安全性和治理能力
|
||||
- [[Cloud Guardrails]]:云守护栏,捕获可扩展性、成本最小化和灵活性的强制性要求
|
||||
- [[Infrastructure as Code]]:通过代码实现一致性、版本控制的基础设施管理
|
||||
|
||||
## Key Entities
|
||||
- [[Gruntwork]]:Landing Zone 框架提供商
|
||||
- [[AWS]]:全球最大公有云平台
|
||||
- [[Cloud Technology Design Forum]]:标准化和集中化微焦点云交付产品的组织
|
||||
|
||||
## Connections
|
||||
- [[Gruntwork Landing Zone]] ← depends_on ← [[AWS Organizations]]
|
||||
- [[Gruntwork Landing Zone]] ← uses ← [[Terraform]]
|
||||
- [[Multi-Account Strategy]] ← implements ← [[Cloud Guardrails]]
|
||||
|
||||
## Contradictions
|
||||
- (暂无记录)
|
||||
50
wiki/sources/ctp-topic-36-sendgrid-as-an-email-service.md
Normal file
50
wiki/sources/ctp-topic-36-sendgrid-as-an-email-service.md
Normal file
@@ -0,0 +1,50 @@
|
||||
---
|
||||
title: "CTP Topic 36 SendGrid as an email service"
|
||||
type: source
|
||||
tags:
|
||||
- SendGrid
|
||||
- Email Service
|
||||
- CTP
|
||||
- Cloud Transformation
|
||||
date: 2026-04-14
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/08_Networking/ctp-topic-36-sendgrid-as-an-email-service.md]]
|
||||
|
||||
## Summary
|
||||
|
||||
- 核心主题:SendGrid 被采用为云转换计划的标准化邮件服务
|
||||
- 问题域:替换不安全的语义网关和受限制的 SES 方案
|
||||
- 方法/机制:直接发送(需 TLS)或通过中继服务器发送架构
|
||||
- 结论价值:SendGrid 提供 1000 收件人/邮件限制、实时监控、双因素认证、端到端加密
|
||||
|
||||
## Key Claims
|
||||
|
||||
- SendGrid 已被采用为经典和新 landing zones 的标准邮件服务
|
||||
- 当前语义网关存在安全问题:通过 port 25 中继到公网,且托管在即将停用的本地网络
|
||||
- 当前 SES 限制为每邮件仅 50 个收件人
|
||||
- SendGrid 支持每邮件最多 1000 个收件人
|
||||
- 支持计划涵盖每月 500 万封邮件
|
||||
- 日志保留 7 天,API 密钥每 180 天轮换
|
||||
|
||||
## Key Concepts
|
||||
|
||||
- [[SendGrid]]:Twilio 旗下的企业级邮件服务,被 CTP 采用为标准
|
||||
- [[Cyber-Suite]]:PSAC 更新发布的网络安全标准文档
|
||||
|
||||
## Connections
|
||||
|
||||
- [[CTP-Topic-35]] ← depends_on ← SendGrid 部署
|
||||
- [[CTP-Topic-7]] ← extends ← Landing Zone 邮件架构
|
||||
- [[CTP-Topic-46]] ← similar ← 企业服务标准化
|
||||
|
||||
## Key Quotes
|
||||
|
||||
> "SendGrid is being adopted as the standard email service for both classic and new landing zones"
|
||||
|
||||
> "Almost 30 billion emails per month customers are already used across the whole country"
|
||||
|
||||
---
|
||||
|
||||
*摄取时间:2026-04-19*
|
||||
@@ -0,0 +1,49 @@
|
||||
---
|
||||
title: "CTP Topic 40 SaaS Database Architecture On AWS Cloud"
|
||||
type: source
|
||||
tags: [SaaS, Database, Architecture, AWS, CTP]
|
||||
date: 2026-04-14
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-40-saas-database-architecture-on-aws-cloud.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题:AWS 云上 SaaS 数据库架构设计,SaaS 数据库团队的全球运维实践
|
||||
- 问题域:多区域数据库运维、多租户数据隔离、数据库高可用与灾备
|
||||
- 方法/机制:Oracle Data Guard、Postgres Active-Passive、RDS High Availability
|
||||
- 结论/价值:提供 24/7 支持,管理 500+ 数据库和 1000+ 服务器,支持 Oracle、Vertica、Postgres、DynamoDB、SQL Server、MongoDB、MySQL 等多种数据库
|
||||
|
||||
## Key Claims
|
||||
- SAS 数据库团队分布在全球多个国家(美国、加拿大、印度、以色列),提供全天候支持
|
||||
- 团队拥有 Oracle 认证专家、DBA 和安全专业人员
|
||||
- 数据库主要部署在应用 VPC 中,集成安全措施
|
||||
- 使用 Oracle Data Guard 实现高可用,Postgres 使用 Active-Passive 机制,计划迁移到 Active Active
|
||||
- 数据库运行在区域内两个可用区,主数据库在第一区,备用在第二区,第三区作为观察者管理故障转移
|
||||
|
||||
## Key Quotes
|
||||
> "The idea was to move those databases seamless without downtime or with minimum downtime." — 数据库迁移目标
|
||||
|
||||
> "Reporting databases have a read-only warehouse in the third availability zone, with secure VPN access for customers to run operational warehousing queries." — 报表数据库架构
|
||||
|
||||
## Key Concepts
|
||||
- [[Multi-Tenant Management]]:多租户 SaaS 数据库管理
|
||||
- [[High-Availability]]:高可用架构设计
|
||||
- [[故障转移]]:自动故障转移机制
|
||||
- [[Database Migration]]:数据中心迁移到云端
|
||||
|
||||
## Key Entities
|
||||
- [[AWS]]:AWS 云平台
|
||||
- [[Amazon Aurora]]:Postgres Aurora 数据库
|
||||
- [[Amazon DynamoDB]]:DynamoDB 数据库
|
||||
- [[Amazon ElastiCache]]:ElastiCache Redis 缓存
|
||||
- [[Oracle]]:Oracle 数据库
|
||||
- [[PostgreSQL]]:PostgreSQL 数据库
|
||||
|
||||
## Connections
|
||||
- [[CTP Topic 35 AWS Landing Zone Design Refresher (SaaS Labs)]] ← uses ← [[ctp-topic-40-saas-database-architecture-on-aws-cloud]]
|
||||
- [[CTP Topic 51 Architecting with AWS Purpose-Built Databases]] ← extends ← [[ctp-topic-40-saas-database-architecture-on-aws-cloud]]
|
||||
- [[CTP Topic 66 Exposing the differences between PostgreSQL RDS and Aurora]] ← relates_to ← [[ctp-topic-40-saas-database-architecture-on-aws-cloud]]
|
||||
|
||||
## Contradictions
|
||||
- (暂无)
|
||||
50
wiki/sources/ctp-topic-50-ami-roadmap-for-aws-amis.md
Normal file
50
wiki/sources/ctp-topic-50-ami-roadmap-for-aws-amis.md
Normal file
@@ -0,0 +1,50 @@
|
||||
---
|
||||
title: "CTP Topic 50 AMI Roadmap for AWS AMIs"
|
||||
type: source
|
||||
tags:
|
||||
- AWS
|
||||
- AMI
|
||||
- Roadmap
|
||||
- CTP
|
||||
date: 2026-04-18
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-50-ami-roadmap-for-aws-amis.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题:AWS AMI(Amazon Machine Image)路线图与标准化 AMI 维护策略
|
||||
- 问题域:企业云环境中的机器镜像治理,涵盖操作系统版本支持生命周期、新 AMI 添加流程、标准化功能集成
|
||||
- 方法/机制:CCOE(Cloud Center of Excellence)每两个月发布一次加固 AMI,遵循安全标准
|
||||
- 结论/价值:标准化 AMI 体系确保环境一致性、安全合规性,路线图透明化管理便于规划
|
||||
|
||||
## Key Claims
|
||||
- CCOE 每两个月发布一次符合安全标准的加固 AMI
|
||||
- 当前支持的 AMI 包括:Ubuntu(3个版本)、CentOS 7/8、Rocky 8.4 ARM、Amazon Linux 2、Windows(4个版本)
|
||||
- 路线图按 ADM 需求优先级排序,如需调整需通过需求管道流程
|
||||
|
||||
## Key Quotes
|
||||
> "The CCOE provides hardened AMIs on a bi-monthly basis aligned with security standards."
|
||||
|
||||
> "Any requirements to change the prioritization of the roadmap should go through the demand pipeline process."
|
||||
|
||||
> "The AMIs are shared with every account in the organization, including the AMI itself, EBS volumes, and KMS keys."
|
||||
|
||||
## Key Concepts
|
||||
- **Standard AMI**:AWS 标准机器镜像,包含 OS 加固、最新安全补丁,支持域集成、SSM agent、DNS 设置
|
||||
- **AMI 路线图**:按月发布计划,2022年11月 SLES 15 + RHEL 9,2023年1月 OpenSUSE 15 + Amazon Linux 2022,2023年3月 Rocky 8 + Rocky 9,2023年5月 RHEL 9.4 ARM + Ubuntu 22.04 ARM
|
||||
- **EOL(End of Life)**:Windows Server 2008/2008 R2(2020.01),CentOS 8(2021.12),Windows Server 2012(2023.10),RHEL 7 + CentOS 7(2024.06)
|
||||
- **Change Log**:CCOE 门户提供与上一版本的变更记录
|
||||
- **AMI 添加流程**:服务集成→功能启用→构建测试
|
||||
|
||||
## Key Entities
|
||||
- [[AWS]]:云平台,提供 EC2 和 AMI 服务
|
||||
- [[CCOE]]:Cloud Center of Excellence,负责 AMI 标准制定和发布
|
||||
|
||||
## Connections
|
||||
- [[Standard AMI]] ← depends_on ← [[AWS EC2]]
|
||||
- [[CTP Topic 26 Standard AMI]] ← extends ← [[CTP Topic 50]]
|
||||
- [[Gruntwork Landing Zone]] ← uses ← [[Standard AMI]]
|
||||
|
||||
## Contradictions
|
||||
- 与非标准 AMI 对比:企业需要平衡自定义灵活性与标准化安全合规要求
|
||||
57
wiki/sources/ctp-topic-58-aws-ec2-image-builder.md
Normal file
57
wiki/sources/ctp-topic-58-aws-ec2-image-builder.md
Normal file
@@ -0,0 +1,57 @@
|
||||
---
|
||||
title: "CTP Topic 58 AWS EC2 Image Builder"
|
||||
type: source
|
||||
tags: [AWS, EC2, Image Builder, CTP]
|
||||
date: 2026-04-14
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-58-aws-ec2-image-builder.md]]
|
||||
|
||||
## Summary
|
||||
|
||||
- **核心主题**: AWS EC2 Image Builder 服务,用于自动创建、管理和分发 AMIs 和 Docker 镜像
|
||||
- **问题域**: 企业镜像构建标准化、CI/CD 流程优化、安全加固自动化
|
||||
- **方法/机制**:
|
||||
- Image Pipeline 定义 AMI 发布方式,包括安装、安全加固和发布计划
|
||||
- Image Recipe(YAML 格式)定义源 AMI 和输出 AMI 规格
|
||||
- Component 定义在源 AMI 中执行的具体步骤(安装包或 shell 命令)
|
||||
- Infrastructure Configuration 定义实例属性(实例类型、VPC、子网、安全组)
|
||||
- Distribution Settings 管理跨区域和账号的 AMI 分发
|
||||
|
||||
## Key Claims
|
||||
|
||||
- Image Builder 通过自动化提高生产力,在构建过程中集成测试,加载安全加固标准
|
||||
- 与 AWS Organizations 和 AWS RAM 集成,支持跨托管账号分发 AMI
|
||||
- 当前 AMI 发布流程存在缺陷:修改周转时间长、AMI 不兼容、手动流程自动化程度低
|
||||
|
||||
## Key Quotes
|
||||
|
||||
> "A component is basically just a particular step that you want to execute in order to achieve the output AMI."
|
||||
|
||||
> "Due to these limitations, product teams try to cater to their requirements by developing their own workflow or CI/CD pipelines, consuming the CCOE AMI and installing their required packages."
|
||||
|
||||
## Key Concepts
|
||||
|
||||
- [[EC2 Image Builder]]: AWS 托管服务,用于自动化创建、管理和分发 AMIs 和 Docker 镜像
|
||||
- [[Standard AMI]]: 包含 OS 加固脚本、安全补丁的标准化机器镜像
|
||||
- [[Infrastructure as Code]]: 通过 Terraform 模块创建和管理 Image Builder 资源
|
||||
|
||||
## Key Entities
|
||||
|
||||
- [[AWS]]: Amazon Web Services,云服务提供商
|
||||
- [[Terraform]]: 基础设施即代码工具,用于创建和管理 Image Builder 资源
|
||||
- [[CTP]]: Cloud Transformation Program,云转型计划项目
|
||||
|
||||
## Connections
|
||||
|
||||
- [[AWS]] ← provides ← [[EC2 Image Builder]]
|
||||
- [[EC2 Image Builder]] ← uses ← [[Terraform]] ← manages_infrastructure ← [[Standard AMI]]
|
||||
- [[CTP]] ← consumes ← [[Standard AMI]]
|
||||
|
||||
## Contradictions
|
||||
|
||||
- **与手动 AMI 构建流程**:
|
||||
- **冲突点**: 手动 AMI 构建和 EC2 Image Builder 的取舍
|
||||
- **当前观点**: 手动流程效率低,周转时间长,不适合大规模自动化
|
||||
- **对方观点**: 手动流程提供更多控制,适合特定场景
|
||||
62
wiki/sources/ctp-topic-68-introduction-to-redshift.md
Normal file
62
wiki/sources/ctp-topic-68-introduction-to-redshift.md
Normal file
@@ -0,0 +1,62 @@
|
||||
---
|
||||
title: "CTP Topic 68 Introduction to Redshift"
|
||||
type: source
|
||||
tags: [AWS, Redshift, Data-Warehouse, CTP]
|
||||
sources: []
|
||||
last_updated: 2026-04-14
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-68-introduction-to-redshift.md]]
|
||||
|
||||
## Summary
|
||||
|
||||
- 核心主题:AWS Redshift 数据仓库架构与核心组件
|
||||
- 问题域:云端数据仓库服务、数据仓库架构设计
|
||||
- 方法/机制:MPP 并行处理、列式存储、数据压缩、Sort Key、Dist Key
|
||||
- 结论/价值:Redshift 是完全托管的 PB 级云端数据仓库解决方案,支持 OLAP,提供易用的安装维护、备份恢复和跨区域灾备
|
||||
|
||||
## Key Claims
|
||||
|
||||
- Redshift 是一种完全托管的 PB 级云端数据仓库服务,专为数据仓库场景设计,支持 OLAP(在线分析处理)
|
||||
- Redshift 架构包含 Leader Node(领导节点)和 Compute Node(计算节点),Leader 节点负责 schema 管理、元数据和查询规划,计算节点执行查询
|
||||
- RA3 实例类型使用 AWS 托管的 NVMe 存储,具有成本效益和大存储容量
|
||||
- MPP(大规模并行处理)使查询能够跨多个计算节点并行处理,提升查询速度和响应时间
|
||||
- 列式存储针对数据仓库操作进行了性能优化,相比行式存储具有更快的性能和更低的内存占用
|
||||
- Sort Key 和 Dist Key 在优化查询性能和管理计算节点间数据分布方面起关键作用
|
||||
|
||||
## Key Quotes
|
||||
|
||||
> "Redshift is a fully managed, petabyte-scale data warehouse solution in the cloud. It is designed for data warehousing, enabling quick data retrieval from large datasets." — 视频摘要
|
||||
|
||||
> "The leader node manages schema, warehouse metadata, and query planning, distributes instructions to compute nodes." — 视频摘要
|
||||
|
||||
> "The leader node then stores results in buffers for quick retrieval, enhancing performance." — 视频摘要
|
||||
|
||||
## Key Concepts
|
||||
|
||||
- [[MPP]]:大规模并行处理,使查询跨多个计算节点并行处理
|
||||
- [[列式存储]]:针对数据仓库操作优化的存储方式,提高查询性能
|
||||
- [[Sort-Key]]:排序键,决定数据在磁盘上的物理排序顺序
|
||||
- [[Dist-Key]]:分布键,决定数据在计算节点间的分布方式
|
||||
- [[数据压缩]]:Redshift 支持多种压缩编码(如 LZO),减少存储空间和 I/O
|
||||
- [[OLAP]]:在线分析处理,用于复杂查询和数据分析
|
||||
|
||||
## Key Entities
|
||||
|
||||
- [[AWS]]:Amazon Web Services,Redshift 数据仓库服务提供商
|
||||
- [[AWS-Redshift]]:Amazon Redshift,PB 级云端数据仓库服务
|
||||
- [[Leader-Node]]:领导节点,Redshift 集群的管理节点
|
||||
- [[Compute-Node]]:计算节点,执行实际查询的节点
|
||||
|
||||
## Connections
|
||||
|
||||
- [[AWS]] → provides → [[AWS-Redshift]]
|
||||
- [[AWS-Redshift]] → uses → [[Leader-Node]]
|
||||
- [[AWS-Redshift]] → uses → [[Compute-Node]]
|
||||
- [[Compute-Node]] → supports → [[MPP]]
|
||||
- [[列式存储]] → optimizes → [[AWS-Redshift]]
|
||||
|
||||
## Contradictions
|
||||
|
||||
- 暂无
|
||||
58
wiki/sources/ctp-topic-7-saas-landing-zone-design.md
Normal file
58
wiki/sources/ctp-topic-7-saas-landing-zone-design.md
Normal file
@@ -0,0 +1,58 @@
|
||||
---
|
||||
title: "CTP Topic 7 SaaS Landing Zone Design"
|
||||
type: source
|
||||
tags:
|
||||
- AWS
|
||||
- Landing-Zone
|
||||
- SaaS
|
||||
- CTP
|
||||
- Cloud-Learning
|
||||
date: 2026-04-14
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-7-saas-landing-zone-design.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题:生产环境 SaaS Landing Zone 的高级设计
|
||||
- 问题域:多账号架构、基础设施自动化、安全隔离
|
||||
- 方法/机制:单一 Landing Zone 策略、Terraform 模块化部署、TerraGrant 权限管理
|
||||
- 结论/价值:统一 Landing Zone 降低开销和复杂度,与开发实验室的每产品组(PG) Landing Zone 模式区分
|
||||
|
||||
## Key Claims
|
||||
- SaaS 生产环境采用单一 Landing Zone 策略,服务所有产品组,降低基础设施开销和运维复杂度
|
||||
- Shared Account 托管硬化的 SRE-provided AMIs 和主 Jenkins 服务器,通过 Lambda 函数触发各账号的 Jenkins slaves 执行部署任务
|
||||
- Logs Account 集中收集所有账号的 CloudTrail、Config、Flowlogs,安全团队拥有完全访问权限,产品团队仅可访问自身日志
|
||||
- Security Account 承载跨账号继承的 IAM Role,各账号所有者可附加额外策略限制 Role 使用范围
|
||||
|
||||
## Key Quotes
|
||||
> "The SAS landing zone will use a single landing zone for all the product groups." — 单一 Landing Zone 策略的核心声明
|
||||
>
|
||||
> "The workload itself is going to be under private subnet." — 产品账号工作负载部署模式
|
||||
|
||||
## Key Concepts
|
||||
- [[Multi-Account Strategy]]:AWS 推荐的企业级云架构模式,通过将工作负载分离到多个 AWS 账号提升安全性和治理能力
|
||||
- [[Gruntwork Landing Zone]]:基于 Grant 工作参考架构的预配置 AWS 基础架构框架
|
||||
- [[Terraform]]:基础设施即代码工具,用于自动化部署和管理 AWS 资源
|
||||
- [[SRE-provided AMIs]]:SRE 团队预构建的机器镜像,内置自动域加入脚本
|
||||
- [[Domain Join]]:通过 SRE-provided AMIs 实现自动化将实例加入 AD 域的技术
|
||||
|
||||
## Key Entities
|
||||
- [[AWS]]:全球最大公有云平台,提供计算、存储、网络等基础架构服务
|
||||
- [[Gruntwork]]:Gruntwork Landing Zones 框架提供商
|
||||
- [[Jenkins]]:开源自动化服务器,用于持续集成和持续部署
|
||||
- [[Route 53]]:AWS DNS 服务,用于管理域名解析
|
||||
- [[Active Directory]]:Microsoft 目录服务,用于身份验证和资源访问控制
|
||||
- [[CloudFront]]:AWS 内容分发网络(CDN),用于加速静态内容分发
|
||||
- [[WAF]]:Web Application Firewall,Web 应用防火墙,用于保护 Web 应用免受攻击
|
||||
- [[Check Point]]:网络安全公司,提供防火墙和 VPN 解决方案
|
||||
- [[Pulse Secure]]:VPN 解决方案供应商,提供安全的远程访问
|
||||
|
||||
## Connections
|
||||
- [[ctp-topic-35-aws-landing-zone-design-refresher-saas-labs]] ← similar_architecture ← [[ctp-topic-7-saas-landing-zone-design]]
|
||||
- [[ctp-topic-1-gruntwork-landing-zone-architecture]] ← builds_on ← [[ctp-topic-7-saas-landing-zone-design]]
|
||||
- [[ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security]] ← relates_to ← [[ctp-topic-7-saas-landing-zone-design]]
|
||||
- [[ctp-topic-17-active-directory-services-in-gruntwork-aws-lzs]] ← depends_on ← [[ctp-topic-7-saas-landing-zone-design]]
|
||||
|
||||
## Contradictions
|
||||
- 与 Labs 环境的区别:生产环境采用单一 Landing Zone,Labs 环境采用每个产品组独立的 Landing Zone
|
||||
@@ -0,0 +1,48 @@
|
||||
---
|
||||
title: "Learning Sessions Standard AMIs Updates 20231205"
|
||||
type: source
|
||||
tags: [AWS, AMI, Cloud, DevOps]
|
||||
date: 2023-12-05
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/learning-sessions-standard-amis-updates-20231205-160324-meeting-recording-2.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题:AWS Standard AMIs(标准机器镜像)的概述、更新和发布流程
|
||||
- 问题域:云基础设施标准化、企业镜像管理
|
||||
- 方法/机制:每两个月构建测试发布、JMES 多分支流水线、Jenkins自动化
|
||||
- 结论/价值:提供包含 OS 加固、最新的安全补丁和域集成的标准化 AMIs,支持 23 种不同操作系统
|
||||
|
||||
## Key Claims
|
||||
- Standard AMIs 基于 AWS AMIs,增加了 OS 加固、最新补丁、安全更新,并支持域集成、安全工具、端点保护、SSM agent、DNS 设置
|
||||
- AMIs 每两个月构建、测试并共享到所有 AWS 账户,立即作为私有 AMIs 可用
|
||||
- 目前支持 23 种不同 AMIs,包括各种 Amazon Linux、CentOS、Oracle、Red Hat、Rocky Linux、SUSE、Ubuntu 和 Windows Server 版本
|
||||
- 使用机器人框架将单个 AMI 的验证时间从 3-4 天缩短到 60 分钟
|
||||
|
||||
## Key Quotes
|
||||
> "The AMIs are built, tested, and shared to all AWS accounts every two months, and are immediately available as private AMIs."
|
||||
> — 镜像发布机制说明
|
||||
|
||||
> "We integrated a robotic framework and we reduced the validation time for one AMI from three-four days to 60 minutes."
|
||||
> — 自动化验证效果
|
||||
|
||||
## Key Concepts
|
||||
- [[Standard AMI]]:AWS 标准机器镜像,包含 OS 加固、安全更新的预配置镜像
|
||||
- [[AMI Roadmap]]:AMI 路线图,规划未来操作系统版本支持
|
||||
- [[EC2 Image Builder]]:AWS EC2 镜像构建器,用于创建和维护自定义 AMIs
|
||||
- [[AMI End-of-Life]]:操作系统到达生命周期终点,需要迁移替代方案(如 CentOS 7 迁移到 Rocky Linux)
|
||||
|
||||
## Key Entities
|
||||
- [[AWS]]:Amazon Web Services,云服务提供商
|
||||
- [[Jenkins]]:开源自动化服务器,用于 CI/CD 流水线
|
||||
- [[Amazon Inspector]]:AWS 安全漏洞扫描服务
|
||||
|
||||
## Connections
|
||||
- [[Standard AMI]] ← uses ← [[EC2 Image Builder]]
|
||||
- [[Standard AMI]] ← tested_by ← [[Amazon Inspector]]
|
||||
- [[Standard AMI]] ← built_by ← [[Jenkins]]
|
||||
- [[AMI Roadmap]] ← managed_by ← [[AWS]]
|
||||
|
||||
## Contradictions
|
||||
- (暂无)
|
||||
Reference in New Issue
Block a user