Update nexus: fix conflicts and sync local changes
This commit is contained in:
Shen Wei
@@ -1,89 +1,89 @@
|
||||
---
|
||||
title: "CTP Topic 1 Gruntwork Landing Zone Architecture"
|
||||
type: cloud-learning
|
||||
source-type: video
|
||||
category: "DevOps & SRE/01_AWS-Landing-Zone"
|
||||
tags:
|
||||
- AWS
|
||||
- Landing-Zone
|
||||
- Gruntwork
|
||||
- CTP
|
||||
date-added: 2026-04-14
|
||||
video-source: "nas:///volume2/work/Public Cloud Learning Sessions/CTP _ Topic 1_ Gruntwork Landing Zone Architecture.mp4"
|
||||
audio-source: ""
|
||||
status: summarized (Gemini 摘要)
|
||||
---
|
||||
|
||||
# CTP Topic 1 Gruntwork Landing Zone Architecture
|
||||
|
||||
**Source:** NAS `/volume2/work/Public Cloud Learning Sessions/CTP _ Topic 1_ Gruntwork Landing Zone Architecture.mp4`
|
||||
|
||||
**Type:** VIDEO | **Category:** 01_AWS-Landing-Zone
|
||||
|
||||
**Status:** ✅ 已完成（Gemini 摘要）
|
||||
|
||||
---
|
||||
|
||||
## 摘要
|
||||
|
||||
本次会议主要讨论了基于 Gruntwork 的云平台 Landing Zone 架构，以及如何在云转型项目中应用最佳实践。Gruntwork 是一个拥有大量 Terraform 代码的组织，其代码经过多次实践验证，被认为是最佳实践。会议介绍了参考架构（Reference Architecture）和 Landing Zone 的概念，以及它们在不同环境和账户中的实现方式。参考架构是一个起点，包含共享、日志和安全等核心账户，以及生产、测试和开发等工作负载账户。Landing Zone 基于 Gruntwork，但不包含具体的 ECS 集群或 RDS 数据库，而是由产品团队自行定义。安全账户使用联邦用户，通过 AD 组映射到 IAM 角色。会议还强调了 Jenkins 在 CI/CD 流程中的作用，每个 Landing Zone 都有一个 Jenkins 服务器来部署基础设施变更，每个产品团队也有自己的 Jenkins 任务来部署其负责的基础设施。此外，会议还讨论了 Git 工作流，强调使用特性分支进行开发，并通过 Pull Request 合并到主分支。最后，会议介绍了 Gruntwork 的 Terraform AWS 服务目录，强调服务应具有业务上下文，而非简单的资源。
|
||||
|
||||
---
|
||||
|
||||
## 关键概念
|
||||
|
||||
- **参考架构 (Reference Architecture)**: 一套最佳实践的集合，作为云平台部署的起点，包含核心账户和工作负载账户。
|
||||
- **Landing Zone**: 基于 Gruntwork 的云平台环境，包含安全、共享和日志等核心账户，以及由产品团队自定义的工作负载账户。
|
||||
- **联邦用户 (Federated User)**: 通过 AD 组映射到 IAM 角色，用于访问云平台资源，替代了传统的 IAM 用户。
|
||||
- **CI/CD 流程**: 使用 Jenkins 进行持续集成和持续交付，通过特性分支、Pull Request 和审批流程来管理基础设施变更。
|
||||
- **Terraform AWS 服务目录**: Gruntwork 提供的 Terraform 模块集合，用于构建具有业务上下文的云服务。
|
||||
|
||||
---
|
||||
|
||||
## 行动项
|
||||
|
||||
- [ ] 熟悉 Gruntwork 的 Terraform AWS 服务目录，了解可用的模块和服务。
|
||||
- [ ] 遵循 Git 工作流，使用特性分支进行开发，并通过 Pull Request 合并到主分支。
|
||||
- [ ] 了解 Jenkins 在 CI/CD 流程中的作用，以及如何配置 Jenkins 任务来部署基础设施变更。
|
||||
- [ ] 熟悉联邦用户的配置方式，以及如何通过 AD 组映射到 IAM 角色。
|
||||
- [ ] 确定 Active Directory 连接的具体配置，特别是 corp.joml 还是 swing throw。
|
||||
|
||||
---
|
||||
|
||||
## 相关视频
|
||||
|
||||
> [!info]+ 交叉引用
|
||||
> [[ctp-topic-XX-git-workflow.md]] — 详细解释了 Git 工作流的最佳实践。
|
||||
|
||||
|
||||
## 关键概念
|
||||
|
||||
- **Reference Architecture**: 包含核心账户（Shared/Logs/Security）和工作负载账户（Prod/Stage/Dev）的最佳实践起点
|
||||
- **Landing Zone**: 基于 Gruntwork 仓库的基础设施部署单元，每个 Zone 有独立 GitHub 仓库管理 IaC
|
||||
- **Federated Access**: 通过 AD 组映射到 IAM 角色的联邦身份访问，简化安全账户管理
|
||||
- **Gruntwork Modules**: 经过实战验证的 Terraform 模块，提供业务上下文和粒度支持
|
||||
- **CI/CD Pipeline**: 基于特性分支 + PR + Jenkins 的基础设施变更自动化流程
|
||||
|
||||
---
|
||||
|
||||
## 行动项
|
||||
|
||||
- [ ] 熟悉 Gruntwork Terraform AWS Service Catalog，了解可用模块
|
||||
- [ ] 采用特性分支开发流程，通过 PR 合并到主分支
|
||||
- [ ] 配置 Jenkins 流水线，实现 Terraform Plan/Apply 自动化
|
||||
- [ ] 探索 TerraTest 用于基础设施变更的自动化测试
|
||||
- [ ] 确定 Active Directory 联邦访问的具体配置方案
|
||||
|
||||
---
|
||||
|
||||
## 相关视频
|
||||
|
||||
> [!info]+ 交叉引用
|
||||
> [[ctp-topic-2-git]] — Git 版本控制基础（CI/CD 前提）
|
||||
> [[ctp-topic-3-deploy-and-maintain-infrastructure]] — Terraform 部署与维护
|
||||
> [[ctp-topic-9-ci-cd-with-gruntwork]] — Gruntwork CI/CD 流水线实践
|
||||
> [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security]] — Landing Zone 安全配置
|
||||
|
||||
---
|
||||
|
||||
*最后更新: 2026-04-15*
|
||||
---
|
||||
title: "CTP Topic 1 Gruntwork Landing Zone Architecture"
|
||||
type: cloud-learning
|
||||
source-type: video
|
||||
category: "DevOps & SRE/01_AWS-Landing-Zone"
|
||||
tags:
|
||||
- AWS
|
||||
- Landing-Zone
|
||||
- Gruntwork
|
||||
- CTP
|
||||
date-added: 2026-04-14
|
||||
video-source: "nas:///volume2/work/Public Cloud Learning Sessions/CTP _ Topic 1_ Gruntwork Landing Zone Architecture.mp4"
|
||||
audio-source: ""
|
||||
status: summarized (Gemini 摘要)
|
||||
---
|
||||
|
||||
# CTP Topic 1 Gruntwork Landing Zone Architecture
|
||||
|
||||
**Source:** NAS `/volume2/work/Public Cloud Learning Sessions/CTP _ Topic 1_ Gruntwork Landing Zone Architecture.mp4`
|
||||
|
||||
**Type:** VIDEO | **Category:** 01_AWS-Landing-Zone
|
||||
|
||||
**Status:** ✅ 已完成（Gemini 摘要）
|
||||
|
||||
---
|
||||
|
||||
## 摘要
|
||||
|
||||
本次会议主要讨论了基于 Gruntwork 的云平台 Landing Zone 架构，以及如何在云转型项目中应用最佳实践。Gruntwork 是一个拥有大量 Terraform 代码的组织，其代码经过多次实践验证，被认为是最佳实践。会议介绍了参考架构（Reference Architecture）和 Landing Zone 的概念，以及它们在不同环境和账户中的实现方式。参考架构是一个起点，包含共享、日志和安全等核心账户，以及生产、测试和开发等工作负载账户。Landing Zone 基于 Gruntwork，但不包含具体的 ECS 集群或 RDS 数据库，而是由产品团队自行定义。安全账户使用联邦用户，通过 AD 组映射到 IAM 角色。会议还强调了 Jenkins 在 CI/CD 流程中的作用，每个 Landing Zone 都有一个 Jenkins 服务器来部署基础设施变更，每个产品团队也有自己的 Jenkins 任务来部署其负责的基础设施。此外，会议还讨论了 Git 工作流，强调使用特性分支进行开发，并通过 Pull Request 合并到主分支。最后，会议介绍了 Gruntwork 的 Terraform AWS 服务目录，强调服务应具有业务上下文，而非简单的资源。
|
||||
|
||||
---
|
||||
|
||||
## 关键概念
|
||||
|
||||
- **参考架构 (Reference Architecture)**: 一套最佳实践的集合，作为云平台部署的起点，包含核心账户和工作负载账户。
|
||||
- **Landing Zone**: 基于 Gruntwork 的云平台环境，包含安全、共享和日志等核心账户，以及由产品团队自定义的工作负载账户。
|
||||
- **联邦用户 (Federated User)**: 通过 AD 组映射到 IAM 角色，用于访问云平台资源，替代了传统的 IAM 用户。
|
||||
- **CI/CD 流程**: 使用 Jenkins 进行持续集成和持续交付，通过特性分支、Pull Request 和审批流程来管理基础设施变更。
|
||||
- **Terraform AWS 服务目录**: Gruntwork 提供的 Terraform 模块集合，用于构建具有业务上下文的云服务。
|
||||
|
||||
---
|
||||
|
||||
## 行动项
|
||||
|
||||
- [ ] 熟悉 Gruntwork 的 Terraform AWS 服务目录，了解可用的模块和服务。
|
||||
- [ ] 遵循 Git 工作流，使用特性分支进行开发，并通过 Pull Request 合并到主分支。
|
||||
- [ ] 了解 Jenkins 在 CI/CD 流程中的作用，以及如何配置 Jenkins 任务来部署基础设施变更。
|
||||
- [ ] 熟悉联邦用户的配置方式，以及如何通过 AD 组映射到 IAM 角色。
|
||||
- [ ] 确定 Active Directory 连接的具体配置，特别是 corp.joml 还是 swing throw。
|
||||
|
||||
---
|
||||
|
||||
## 相关视频
|
||||
|
||||
> [!info]+ 交叉引用
|
||||
> [[ctp-topic-XX-git-workflow.md]] — 详细解释了 Git 工作流的最佳实践。
|
||||
|
||||
|
||||
## 关键概念
|
||||
|
||||
- **Reference Architecture**: 包含核心账户（Shared/Logs/Security）和工作负载账户（Prod/Stage/Dev）的最佳实践起点
|
||||
- **Landing Zone**: 基于 Gruntwork 仓库的基础设施部署单元，每个 Zone 有独立 GitHub 仓库管理 IaC
|
||||
- **Federated Access**: 通过 AD 组映射到 IAM 角色的联邦身份访问，简化安全账户管理
|
||||
- **Gruntwork Modules**: 经过实战验证的 Terraform 模块，提供业务上下文和粒度支持
|
||||
- **CI/CD Pipeline**: 基于特性分支 + PR + Jenkins 的基础设施变更自动化流程
|
||||
|
||||
---
|
||||
|
||||
## 行动项
|
||||
|
||||
- [ ] 熟悉 Gruntwork Terraform AWS Service Catalog，了解可用模块
|
||||
- [ ] 采用特性分支开发流程，通过 PR 合并到主分支
|
||||
- [ ] 配置 Jenkins 流水线，实现 Terraform Plan/Apply 自动化
|
||||
- [ ] 探索 TerraTest 用于基础设施变更的自动化测试
|
||||
- [ ] 确定 Active Directory 联邦访问的具体配置方案
|
||||
|
||||
---
|
||||
|
||||
## 相关视频
|
||||
|
||||
> [!info]+ 交叉引用
|
||||
> [[ctp-topic-2-git]] — Git 版本控制基础（CI/CD 前提）
|
||||
> [[ctp-topic-3-deploy-and-maintain-infrastructure]] — Terraform 部署与维护
|
||||
> [[ctp-topic-9-ci-cd-with-gruntwork]] — Gruntwork CI/CD 流水线实践
|
||||
> [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security]] — Landing Zone 安全配置
|
||||
|
||||
---
|
||||
|
||||
*最后更新: 2026-04-15*
|
||||
|
||||
@@ -1,66 +1,66 @@
|
||||
---
|
||||
title: "CTP Topic 10 AWS Landing Zone (LZ) Data Collection, Tagging Related Security"
|
||||
type: cloud-learning
|
||||
source-type: video
|
||||
category: "DevOps & SRE/01_AWS-Landing-Zone"
|
||||
tags:
|
||||
- AWS
|
||||
- Landing-Zone
|
||||
- Tagging
|
||||
- Security
|
||||
- CTP
|
||||
date-added: 2026-04-14
|
||||
video-source: "nas:///volume2/work/Public Cloud Learning Sessions/CTP _ Topic 10_ AWS Landing Zone (LZ) Data Collection, Tagging _ Related Security.mp4"
|
||||
audio-source: ""
|
||||
status: summarized (Gemini 摘要)
|
||||
---
|
||||
|
||||
# CTP Topic 10 AWS Landing Zone (LZ) Data Collection, Tagging Related Security
|
||||
|
||||
**Source:** NAS `/volume2/work/Public Cloud Learning Sessions/CTP _ Topic 10_ AWS Landing Zone (LZ) Data Collection, Tagging _ Related Security.mp4`
|
||||
|
||||
**Type:** VIDEO | **Category:** 01_AWS-Landing-Zone
|
||||
|
||||
**Status:** ✅ 已完成（Gemini 摘要）
|
||||
|
||||
---
|
||||
|
||||
## 摘要
|
||||
|
||||
> 本次视频是云转型计划（Cloud Transformation Program）的每周技术分享，重点探讨了 **AWS Landing Zones** 的部署流程、数据收集策略，以及如何利用标签（Tagging）和安全策略构建现代化的云安全架构。会议由 Steve Jarman 和 Pradeep 主讲，旨在帮助团队理解从传统网络安全向基于身份和元数据的云原生安全转型的过程。
|
||||
>
|
||||
> 核心内容分为三个部分：首先，Steve 介绍了 Landing Zone 的规划与自动化。他强调在部署前，必须深入了解业务部门（BU）的资产清单、IP 地址空间及数据敏感性，以便制定合适的安全姿态。目前，DNS、Transit Gateway 等基础服务的创建已通过 SRE 团队实现了高度自动化。
|
||||
>
|
||||
> 其次，视频详细讲解了**基于标签的安全控制机制**。与传统基于 IP 的防火墙规则不同，该方案利用 AWS 标签作为安全凭证。为了防止用户通过篡改标签绕过安全审计，架构中引入了 **OU（组织单元）** 和 **SCP（服务控制策略）**。通过 SCP 的“显式拒绝”逻辑，系统能够强制执行标签规范，确保资源在创建时即具备正确的归属（如 BU、产品、环境等）。
|
||||
>
|
||||
> 最后，Pradeep 演示了 **Checkpoint 防火墙** 中的“有序层（Ordered Layer）”逻辑。防火墙根据标签对流量进行分层过滤，包括地理屏蔽、BU 隔离、产品隔离及环境隔离（如开发环境与生产环境隔离）。这种设计确保了流量在跨 VPC、访问本地（On-prem）或互联网时，能够受到精细化的策略约束，同时支持 PSDC 等共享服务的合法访问。
|
||||
|
||||
---
|
||||
|
||||
## 关键概念
|
||||
|
||||
- **AWS Landing Zones**: 一种能够按照最佳实践快速设置、安全且多账号的 AWS 环境的基础架构框架。
|
||||
- **Tagging Methodology**: 标签方法论，通过为资源定义标准化的元数据（如 Owner, BU, Product, Environment），作为自动化管理和安全策略执行的基础。
|
||||
- **SCP (Service Control Policies)**: 服务控制策略，一种组织策略，用于管理组织中的权限，本视频中用于强制执行标签合规性，防止未经授权的标签更改。
|
||||
- **OU (Organizational Unit)**: 组织单元，AWS Organizations 中账号的分组容器，用于分层应用安全策略（SCP）。
|
||||
- **Checkpoint Firewall**: 部署在云环境中的虚拟防火墙，通过集成 AWS 标签实现动态的对象识别和流量过滤。
|
||||
- **Transit Gateway**: 传输网关，作为网络中心枢纽，连接 VPC 与本地网络，是跨环境流量经过防火墙检查的关键节点。
|
||||
- **Ordered Layer**: 有序层，防火墙策略的一种组织方式，按顺序执行地理屏蔽、BU 隔离、环境隔离等逻辑。
|
||||
- **SRE (Site Reliability Engineering)**: 站点可靠性工程，负责 Landing Zone 部署中的自动化脚本编写与基础架构维护。
|
||||
|
||||
---
|
||||
|
||||
## 相关视频
|
||||
|
||||
> [!info]+ 交叉引用
|
||||
> [[AWS_Organizations_and_SCP_Deep_Dive]] — 深入探讨如何编写和应用 SCP 策略以增强账号安全性。
|
||||
> [[SRE_Automation_Services_Overview]] — 关联 SRE 团队在 Landing Zone 中实现的 DNS 与网络自动化工具。
|
||||
> [[Hybrid_Cloud_Connectivity_Guide]] — 详细说明 Transit Gateway 如何连接 AWS 环境与本地数据中心。
|
||||
|
||||
## 相关视频
|
||||
|
||||
> 配对视频笔记链接（生成后填入）
|
||||
|
||||
---
|
||||
|
||||
*最后更新: 2026-04-14*
|
||||
---
|
||||
title: "CTP Topic 10 AWS Landing Zone (LZ) Data Collection, Tagging Related Security"
|
||||
type: cloud-learning
|
||||
source-type: video
|
||||
category: "DevOps & SRE/01_AWS-Landing-Zone"
|
||||
tags:
|
||||
- AWS
|
||||
- Landing-Zone
|
||||
- Tagging
|
||||
- Security
|
||||
- CTP
|
||||
date-added: 2026-04-14
|
||||
video-source: "nas:///volume2/work/Public Cloud Learning Sessions/CTP _ Topic 10_ AWS Landing Zone (LZ) Data Collection, Tagging _ Related Security.mp4"
|
||||
audio-source: ""
|
||||
status: summarized (Gemini 摘要)
|
||||
---
|
||||
|
||||
# CTP Topic 10 AWS Landing Zone (LZ) Data Collection, Tagging Related Security
|
||||
|
||||
**Source:** NAS `/volume2/work/Public Cloud Learning Sessions/CTP _ Topic 10_ AWS Landing Zone (LZ) Data Collection, Tagging _ Related Security.mp4`
|
||||
|
||||
**Type:** VIDEO | **Category:** 01_AWS-Landing-Zone
|
||||
|
||||
**Status:** ✅ 已完成（Gemini 摘要）
|
||||
|
||||
---
|
||||
|
||||
## 摘要
|
||||
|
||||
> 本次视频是云转型计划（Cloud Transformation Program）的每周技术分享，重点探讨了 **AWS Landing Zones** 的部署流程、数据收集策略，以及如何利用标签（Tagging）和安全策略构建现代化的云安全架构。会议由 Steve Jarman 和 Pradeep 主讲，旨在帮助团队理解从传统网络安全向基于身份和元数据的云原生安全转型的过程。
|
||||
>
|
||||
> 核心内容分为三个部分：首先，Steve 介绍了 Landing Zone 的规划与自动化。他强调在部署前，必须深入了解业务部门（BU）的资产清单、IP 地址空间及数据敏感性，以便制定合适的安全姿态。目前，DNS、Transit Gateway 等基础服务的创建已通过 SRE 团队实现了高度自动化。
|
||||
>
|
||||
> 其次，视频详细讲解了**基于标签的安全控制机制**。与传统基于 IP 的防火墙规则不同，该方案利用 AWS 标签作为安全凭证。为了防止用户通过篡改标签绕过安全审计，架构中引入了 **OU（组织单元）** 和 **SCP（服务控制策略）**。通过 SCP 的“显式拒绝”逻辑，系统能够强制执行标签规范，确保资源在创建时即具备正确的归属（如 BU、产品、环境等）。
|
||||
>
|
||||
> 最后，Pradeep 演示了 **Checkpoint 防火墙** 中的“有序层（Ordered Layer）”逻辑。防火墙根据标签对流量进行分层过滤，包括地理屏蔽、BU 隔离、产品隔离及环境隔离（如开发环境与生产环境隔离）。这种设计确保了流量在跨 VPC、访问本地（On-prem）或互联网时，能够受到精细化的策略约束，同时支持 PSDC 等共享服务的合法访问。
|
||||
|
||||
---
|
||||
|
||||
## 关键概念
|
||||
|
||||
- **AWS Landing Zones**: 一种能够按照最佳实践快速设置、安全且多账号的 AWS 环境的基础架构框架。
|
||||
- **Tagging Methodology**: 标签方法论，通过为资源定义标准化的元数据（如 Owner, BU, Product, Environment），作为自动化管理和安全策略执行的基础。
|
||||
- **SCP (Service Control Policies)**: 服务控制策略，一种组织策略，用于管理组织中的权限，本视频中用于强制执行标签合规性，防止未经授权的标签更改。
|
||||
- **OU (Organizational Unit)**: 组织单元，AWS Organizations 中账号的分组容器，用于分层应用安全策略（SCP）。
|
||||
- **Checkpoint Firewall**: 部署在云环境中的虚拟防火墙，通过集成 AWS 标签实现动态的对象识别和流量过滤。
|
||||
- **Transit Gateway**: 传输网关，作为网络中心枢纽，连接 VPC 与本地网络，是跨环境流量经过防火墙检查的关键节点。
|
||||
- **Ordered Layer**: 有序层，防火墙策略的一种组织方式，按顺序执行地理屏蔽、BU 隔离、环境隔离等逻辑。
|
||||
- **SRE (Site Reliability Engineering)**: 站点可靠性工程，负责 Landing Zone 部署中的自动化脚本编写与基础架构维护。
|
||||
|
||||
---
|
||||
|
||||
## 相关视频
|
||||
|
||||
> [!info]+ 交叉引用
|
||||
> [[AWS_Organizations_and_SCP_Deep_Dive]] — 深入探讨如何编写和应用 SCP 策略以增强账号安全性。
|
||||
> [[SRE_Automation_Services_Overview]] — 关联 SRE 团队在 Landing Zone 中实现的 DNS 与网络自动化工具。
|
||||
> [[Hybrid_Cloud_Connectivity_Guide]] — 详细说明 Transit Gateway 如何连接 AWS 环境与本地数据中心。
|
||||
|
||||
## 相关视频
|
||||
|
||||
> 配对视频笔记链接（生成后填入）
|
||||
|
||||
---
|
||||
|
||||
*最后更新: 2026-04-14*
|
||||
|
||||
@@ -1,85 +1,85 @@
|
||||
---
|
||||
title: "CTP Topic 14 Octane Hub on AWS Real life experience moving production services into the new land"
|
||||
type: cloud-learning
|
||||
source-type: video
|
||||
category: "DevOps & SRE/01_AWS-Landing-Zone"
|
||||
tags:
|
||||
- AWS
|
||||
- Octane-Hub
|
||||
- Migration
|
||||
- CTP
|
||||
date-added: 2026-04-14
|
||||
video-source: "nas:///volume2/work/Public Cloud Learning Sessions/CTP _ Topic 14_ Octane Hub on AWS_ Real life experience moving production services into the new land.mp4"
|
||||
audio-source: ""
|
||||
status: summarized (Gemini 摘要)
|
||||
---
|
||||
|
||||
# CTP Topic 14 Octane Hub on AWS: Real-Life Experiences
|
||||
|
||||
**Source:** NAS `/volume2/work/Public Cloud Learning Sessions/CTP _ Topic 14_ Octane Hub on AWS_ Real life experience moving production services into the new land.mp4`
|
||||
|
||||
**Type:** VIDEO | **Category:** 01_AWS-Landing-Zone
|
||||
|
||||
**Status: ✅ 已完成摘要**
|
||||
|
||||
---
|
||||
|
||||
## 摘要
|
||||
|
||||
Holger Rode（Octane Hub CTO 软件工厂团队负责人）分享了 Octane Hub 云设计考虑因素、学习曲线、网络和安全要求以及常见陷阱。Octane Hub 团队主要使用 Docker 容器运行，之前托管在 Bibling Lab，拥有三台物理服务器和多台虚拟机。
|
||||
|
||||
### 现有工作负载
|
||||
|
||||
这些容器运行各种 Web 应用程序，包括 QuickSee、Release Manager、Patch Manager 和安全程序板。他们还处理后台作业，如支持集成、数据复制和内部空闲搜索。团队还管理大约 10TB 的文件存储和大型 MSSQL 服务器数据库。
|
||||
|
||||
### 云迁移动因
|
||||
|
||||
由于 Bibling 数据中心即将关闭，云迁移变得紧迫。云转型计划提供了帮助，团队在 5 月左右获得了概念验证 Landing Zone 账户的访问权限，随后在 6 月获得了生产账户。团队目标是实现无缝过渡，紧密镜像现有设置以避免在 Go Live 期间进行重大技术变更。
|
||||
|
||||
### 技术选型与挑战
|
||||
|
||||
- 使用 AWS 定价计算器了解服务成本
|
||||
- 最初考虑 EFS 用于存储，但由于性能问题（数据库无法直接在 EFS 上运行）不适用
|
||||
- 改用 EBS 用于实时数据库，EFS 用于备份
|
||||
- 部署方式：从控制台脚本演变为使用 Packer 构建 AMI，使用 Terraform/TerraGrunt 部署
|
||||
- 网络问题需要多次 PCS 请求，与网络团队协作解决
|
||||
- 使用 VPC Transit Gateway 并实施标签系统管理访问
|
||||
- DNS 设置：使用 Cname 指向 AWS software infra.net 域，通过 Route 53 管理
|
||||
|
||||
### 下一步计划
|
||||
|
||||
- 改进 DR 和高可用性
|
||||
- 通过最佳匹配存储选项（S3）进行成本优化
|
||||
- 从 MSSQL 迁移到 Postgres
|
||||
- 可能迁移到 AWS ECS 服务
|
||||
|
||||
---
|
||||
|
||||
## 关键概念
|
||||
|
||||
- **Docker 容器化**: Octane Hub 的主要部署模式
|
||||
- **Packer + Terraform/TerraGrunt**: 基础设施即代码的部署流程
|
||||
- **VPC Transit Gateway**: AWS 网络互联解决方案
|
||||
- **标签系统**: 基于角色和环境管理资源访问
|
||||
- **EFS vs EBS**: 文件存储与块存储的性能差异
|
||||
|
||||
---
|
||||
|
||||
## 行动项
|
||||
|
||||
- [ ] 评估现有工作负载是否适合容器化
|
||||
- [ ] 规划数据库从 MSSQL 到 Postgres 的迁移路径
|
||||
- [ ] 检查 EBS/EFS 存储选型是否合理
|
||||
- [ ] 制定 DR 和高可用性改进计划
|
||||
|
||||
---
|
||||
|
||||
## 相关视频
|
||||
|
||||
> [!info]+ 交叉引用
|
||||
> [[ctp-topic-7-saas-landing-zone-design]] — SaaS Landing Zone 设计
|
||||
> [[ctp-topic-25-labs-landing-zone-overview-itom-teams]] — Labs Landing Zone 概述
|
||||
|
||||
---
|
||||
|
||||
*最后更新: 2026-04-15*
|
||||
---
|
||||
title: "CTP Topic 14 Octane Hub on AWS Real life experience moving production services into the new land"
|
||||
type: cloud-learning
|
||||
source-type: video
|
||||
category: "DevOps & SRE/01_AWS-Landing-Zone"
|
||||
tags:
|
||||
- AWS
|
||||
- Octane-Hub
|
||||
- Migration
|
||||
- CTP
|
||||
date-added: 2026-04-14
|
||||
video-source: "nas:///volume2/work/Public Cloud Learning Sessions/CTP _ Topic 14_ Octane Hub on AWS_ Real life experience moving production services into the new land.mp4"
|
||||
audio-source: ""
|
||||
status: summarized (Gemini 摘要)
|
||||
---
|
||||
|
||||
# CTP Topic 14 Octane Hub on AWS: Real-Life Experiences
|
||||
|
||||
**Source:** NAS `/volume2/work/Public Cloud Learning Sessions/CTP _ Topic 14_ Octane Hub on AWS_ Real life experience moving production services into the new land.mp4`
|
||||
|
||||
**Type:** VIDEO | **Category:** 01_AWS-Landing-Zone
|
||||
|
||||
**Status: ✅ 已完成摘要**
|
||||
|
||||
---
|
||||
|
||||
## 摘要
|
||||
|
||||
Holger Rode（Octane Hub CTO 软件工厂团队负责人）分享了 Octane Hub 云设计考虑因素、学习曲线、网络和安全要求以及常见陷阱。Octane Hub 团队主要使用 Docker 容器运行，之前托管在 Bibling Lab，拥有三台物理服务器和多台虚拟机。
|
||||
|
||||
### 现有工作负载
|
||||
|
||||
这些容器运行各种 Web 应用程序，包括 QuickSee、Release Manager、Patch Manager 和安全程序板。他们还处理后台作业，如支持集成、数据复制和内部空闲搜索。团队还管理大约 10TB 的文件存储和大型 MSSQL 服务器数据库。
|
||||
|
||||
### 云迁移动因
|
||||
|
||||
由于 Bibling 数据中心即将关闭，云迁移变得紧迫。云转型计划提供了帮助，团队在 5 月左右获得了概念验证 Landing Zone 账户的访问权限，随后在 6 月获得了生产账户。团队目标是实现无缝过渡，紧密镜像现有设置以避免在 Go Live 期间进行重大技术变更。
|
||||
|
||||
### 技术选型与挑战
|
||||
|
||||
- 使用 AWS 定价计算器了解服务成本
|
||||
- 最初考虑 EFS 用于存储，但由于性能问题（数据库无法直接在 EFS 上运行）不适用
|
||||
- 改用 EBS 用于实时数据库，EFS 用于备份
|
||||
- 部署方式：从控制台脚本演变为使用 Packer 构建 AMI，使用 Terraform/TerraGrunt 部署
|
||||
- 网络问题需要多次 PCS 请求，与网络团队协作解决
|
||||
- 使用 VPC Transit Gateway 并实施标签系统管理访问
|
||||
- DNS 设置：使用 Cname 指向 AWS software infra.net 域，通过 Route 53 管理
|
||||
|
||||
### 下一步计划
|
||||
|
||||
- 改进 DR 和高可用性
|
||||
- 通过最佳匹配存储选项（S3）进行成本优化
|
||||
- 从 MSSQL 迁移到 Postgres
|
||||
- 可能迁移到 AWS ECS 服务
|
||||
|
||||
---
|
||||
|
||||
## 关键概念
|
||||
|
||||
- **Docker 容器化**: Octane Hub 的主要部署模式
|
||||
- **Packer + Terraform/TerraGrunt**: 基础设施即代码的部署流程
|
||||
- **VPC Transit Gateway**: AWS 网络互联解决方案
|
||||
- **标签系统**: 基于角色和环境管理资源访问
|
||||
- **EFS vs EBS**: 文件存储与块存储的性能差异
|
||||
|
||||
---
|
||||
|
||||
## 行动项
|
||||
|
||||
- [ ] 评估现有工作负载是否适合容器化
|
||||
- [ ] 规划数据库从 MSSQL 到 Postgres 的迁移路径
|
||||
- [ ] 检查 EBS/EFS 存储选型是否合理
|
||||
- [ ] 制定 DR 和高可用性改进计划
|
||||
|
||||
---
|
||||
|
||||
## 相关视频
|
||||
|
||||
> [!info]+ 交叉引用
|
||||
> [[ctp-topic-7-saas-landing-zone-design]] — SaaS Landing Zone 设计
|
||||
> [[ctp-topic-25-labs-landing-zone-overview-itom-teams]] — Labs Landing Zone 概述
|
||||
|
||||
---
|
||||
|
||||
*最后更新: 2026-04-15*
|
||||
|
||||
@@ -1,62 +1,62 @@
|
||||
---
|
||||
title: "CTP Topic 17 Active Directory Services in Gruntwork AWS LZs"
|
||||
type: cloud-learning
|
||||
source-type: video
|
||||
category: "DevOps & SRE/01_AWS-Landing-Zone"
|
||||
tags:
|
||||
- AWS
|
||||
- Landing-Zone
|
||||
- AD
|
||||
- Gruntwork
|
||||
- CTP
|
||||
date-added: 2026-04-14
|
||||
video-source: "nas:///volume2/work/Public Cloud Learning Sessions/CTP _ Topic 17_ Active Directory Services in Gruntwork AWS LZs.mp4"
|
||||
audio-source: ""
|
||||
status: summarized (Gemini 摘要)
|
||||
---
|
||||
|
||||
# CTP Topic 17 Active Directory Services in Gruntwork AWS LZs
|
||||
|
||||
**Source:** NAS `/volume2/work/Public Cloud Learning Sessions/CTP _ Topic 17_ Active Directory Services in Gruntwork AWS LZs.mp4`
|
||||
|
||||
**Type:** VIDEO | **Category:** 01_AWS-Landing-Zone
|
||||
|
||||
**Status: 🟡 Awaiting Whisper transcription → Summary**
|
||||
|
||||
---
|
||||
|
||||
## 摘要
|
||||
|
||||
> 本次视频是 DevOps 云学习系列课程之一，重点介绍了在 Gruntwork AWS Landing Zones 架构中集成与管理 Active Directory (AD) 服务的核心实践。演讲者 Paul 详细阐述了两种主要环境的域名配置：研发实验室（R&D Labs）统一使用 `swinford.net` 域名，而生产与分阶段 SAS 环境则采用 `intsas.local`。视频明确指出，旧有的 `infra` 和 `AST` 域名在新的 Gruntwork 落地页中已被废弃，并为用户提供了相应的迁移路径和所有权归属建议。
|
||||
>
|
||||
> 在技术实现层面，视频重点讲解了如何利用 SRE 团队提供的预制 AMI（Amazon Machine Images）实现自动化的域加入（Domain Join）。通过在 Terraform 的 `user_data` 中调用内置脚本，Windows 实例可以实现自动命名、管理员权限分配及旧对象清理；Linux 实例则支持安全动态更新以自动注册 DNS A 记录。此外，视频还介绍了针对不同环境的自助服务工具（如 MIM）和支持渠道（如 SMACKS 工单系统），旨在帮助开发者在遵循安全合规的前提下，提升系统接入域的效率与自动化水平。
|
||||
|
||||
---
|
||||
|
||||
## 关键概念
|
||||
|
||||
- **Gruntwork Landing Zones**: 预配置的、基于最佳实践的 AWS 基础架构框架，分为 R&D Labs 和 SAS 两种环境类型。
|
||||
- **swinford.net**: 专门用于研发实验室（R&D Labs）环境的 Active Directory 域名，支持自助服务管理。
|
||||
- **intsas.local**: 用于生产和分阶段 SAS 环境的内部 Active Directory 域名，强调资源的所有权和审计。
|
||||
- **SRE-provided AMIs**: 由 SRE 团队预先构建的机器镜像，内置了用于自动加入域的 PowerShell 和 Shell 脚本。
|
||||
- **User Data**: 在 AWS 实例启动时执行的脚本数据，本视频中用于触发自动化的域加入流程。
|
||||
- **MIM (Microsoft Identity Manager)**: 用于 R&D 环境中安全组管理和权限申请的自助服务解决方案。
|
||||
- **SMACKS Ticket**: 内部服务管理工单系统，用于申请新账号、重置密码或处理复杂的生产环境变更。
|
||||
- **Secure Dynamic Updates**: 一种安全机制，允许 Linux 系统在加入域时向 Windows DNS 服务器安全地注册其 A 记录。
|
||||
|
||||
---
|
||||
|
||||
## 相关视频
|
||||
|
||||
> [!info]+ 交叉引用
|
||||
> [[Gruntwork AWS Landing Zones Overview]] — 了解 AD 服务运行的基础架构背景
|
||||
> [[SRE Standard AMIs and Image Building]] — 了解内置域加入脚本的 AMI 制作标准
|
||||
> [[Terraform Single Server Module Deep Dive]] — 深入理解视频中用于部署实例的 Terraform 模块用法
|
||||
|
||||
## 相关视频
|
||||
|
||||
> 配对视频笔记链接（生成后填入）
|
||||
|
||||
---
|
||||
|
||||
*最后更新: 2026-04-14*
|
||||
---
|
||||
title: "CTP Topic 17 Active Directory Services in Gruntwork AWS LZs"
|
||||
type: cloud-learning
|
||||
source-type: video
|
||||
category: "DevOps & SRE/01_AWS-Landing-Zone"
|
||||
tags:
|
||||
- AWS
|
||||
- Landing-Zone
|
||||
- AD
|
||||
- Gruntwork
|
||||
- CTP
|
||||
date-added: 2026-04-14
|
||||
video-source: "nas:///volume2/work/Public Cloud Learning Sessions/CTP _ Topic 17_ Active Directory Services in Gruntwork AWS LZs.mp4"
|
||||
audio-source: ""
|
||||
status: summarized (Gemini 摘要)
|
||||
---
|
||||
|
||||
# CTP Topic 17 Active Directory Services in Gruntwork AWS LZs
|
||||
|
||||
**Source:** NAS `/volume2/work/Public Cloud Learning Sessions/CTP _ Topic 17_ Active Directory Services in Gruntwork AWS LZs.mp4`
|
||||
|
||||
**Type:** VIDEO | **Category:** 01_AWS-Landing-Zone
|
||||
|
||||
**Status: 🟡 Awaiting Whisper transcription → Summary**
|
||||
|
||||
---
|
||||
|
||||
## 摘要
|
||||
|
||||
> 本次视频是 DevOps 云学习系列课程之一，重点介绍了在 Gruntwork AWS Landing Zones 架构中集成与管理 Active Directory (AD) 服务的核心实践。演讲者 Paul 详细阐述了两种主要环境的域名配置：研发实验室（R&D Labs）统一使用 `swinford.net` 域名，而生产与分阶段 SAS 环境则采用 `intsas.local`。视频明确指出，旧有的 `infra` 和 `AST` 域名在新的 Gruntwork 落地页中已被废弃，并为用户提供了相应的迁移路径和所有权归属建议。
|
||||
>
|
||||
> 在技术实现层面，视频重点讲解了如何利用 SRE 团队提供的预制 AMI（Amazon Machine Images）实现自动化的域加入（Domain Join）。通过在 Terraform 的 `user_data` 中调用内置脚本，Windows 实例可以实现自动命名、管理员权限分配及旧对象清理；Linux 实例则支持安全动态更新以自动注册 DNS A 记录。此外，视频还介绍了针对不同环境的自助服务工具（如 MIM）和支持渠道（如 SMACKS 工单系统），旨在帮助开发者在遵循安全合规的前提下，提升系统接入域的效率与自动化水平。
|
||||
|
||||
---
|
||||
|
||||
## 关键概念
|
||||
|
||||
- **Gruntwork Landing Zones**: 预配置的、基于最佳实践的 AWS 基础架构框架，分为 R&D Labs 和 SAS 两种环境类型。
|
||||
- **swinford.net**: 专门用于研发实验室（R&D Labs）环境的 Active Directory 域名，支持自助服务管理。
|
||||
- **intsas.local**: 用于生产和分阶段 SAS 环境的内部 Active Directory 域名，强调资源的所有权和审计。
|
||||
- **SRE-provided AMIs**: 由 SRE 团队预先构建的机器镜像，内置了用于自动加入域的 PowerShell 和 Shell 脚本。
|
||||
- **User Data**: 在 AWS 实例启动时执行的脚本数据，本视频中用于触发自动化的域加入流程。
|
||||
- **MIM (Microsoft Identity Manager)**: 用于 R&D 环境中安全组管理和权限申请的自助服务解决方案。
|
||||
- **SMACKS Ticket**: 内部服务管理工单系统，用于申请新账号、重置密码或处理复杂的生产环境变更。
|
||||
- **Secure Dynamic Updates**: 一种安全机制，允许 Linux 系统在加入域时向 Windows DNS 服务器安全地注册其 A 记录。
|
||||
|
||||
---
|
||||
|
||||
## 相关视频
|
||||
|
||||
> [!info]+ 交叉引用
|
||||
> [[Gruntwork AWS Landing Zones Overview]] — 了解 AD 服务运行的基础架构背景
|
||||
> [[SRE Standard AMIs and Image Building]] — 了解内置域加入脚本的 AMI 制作标准
|
||||
> [[Terraform Single Server Module Deep Dive]] — 深入理解视频中用于部署实例的 Terraform 模块用法
|
||||
|
||||
## 相关视频
|
||||
|
||||
> 配对视频笔记链接（生成后填入）
|
||||
|
||||
---
|
||||
|
||||
*最后更新: 2026-04-14*
|
||||
|
||||
@@ -1,71 +1,71 @@
|
||||
---
|
||||
title: CTP Topic 25 Labs Landing Zone overview - ITOM teams
|
||||
type: cloud-learning
|
||||
source-type: video
|
||||
category: DevOps & SRE/01_AWS-Landing-Zone
|
||||
tags:
|
||||
- AWS
|
||||
- Landing-Zone
|
||||
- Labs
|
||||
- ITOM
|
||||
- CTP
|
||||
date-added: 2026-04-14
|
||||
video-source: nas:///volume2/work/Public Cloud Learning Sessions/CTP _ Topic 25_ Labs Landing Zone overview - ITOM teams.mp4
|
||||
audio-source: ""
|
||||
status: summarized (Gemini 摘要)
|
||||
---
|
||||
|
||||
# CTP Topic 25 Labs Landing Zone overview - ITOM teams
|
||||
|
||||
**Source:** NAS `/volume2/work/Public Cloud Learning Sessions/CTP _ Topic 25_ Labs Landing Zone overview - ITOM teams.mp4`
|
||||
|
||||
**Type:** VIDEO | **Category:** 01_AWS-Landing-Zone
|
||||
|
||||
**Status:** 🟡 Awaiting Whisper transcription → Summary
|
||||
|
||||
---
|
||||
|
||||
## 摘要
|
||||
|
||||
> ## Labs Landing Zone Overview
|
||||
|
||||
The Labs landing zone is based on the Gruntworks reference architecture and AWS standards, utilizing a multi-account strategy. The entire stack is managed through infrastructure as code (Terraform), using a library of common functions accessible for review and modification. *Everything should be managed using Terraform or some other code-based mechanism.*
|
||||
|
||||
Key components include:
|
||||
|
||||
* **Shared Account:** Hosts the Jenkins master for the CI/CD pipeline (Gruntworks production grade), hardened AMIs, and a Docker container store.
|
||||
* **Logs Account:** Secure storage for AWS Config and CloudTrail logs, with access controlled by the security team.
|
||||
* **Security Account:** Manages user accounts and access, primarily for cross-account access and shared accounts, with most access being federated.
|
||||
* **Core Accounts:**
|
||||
* Active Directory: Manages Windows instances and IDPs (all in Swimford.net).
|
||||
* DNS: Manages AWS Swimford.net, allowing for local domains or referencing the wider infrastructure.
|
||||
* **Network Account:** Central hub for network communication, managing traffic via Transit Gateway and JetPult firewall. All internet access is routed through here, managed by the network team via tags. Pulse VPN access is also managed here, providing access to the micro focus network.
|
||||
* **Shared Service Accounts:** Provide access to services like monitoring (45 arc site) and Qualys.
|
||||
* **Product Account:** The primary working environment, built to standard infrastructure-as-code modules. It can have multiple accounts (production, staging, development). Logs are shipped to the logs account, and Jenkins manages automation within the account.
|
||||
|
||||
When deploying a product account, key requirements include defining IP address ranges and agreeing on specific tags with the network team for firewall access. *Access through that firewall is all managed by tags.* The team recommends using their Terraform modules for deploying subnets.
|
||||
|
||||
The standard Jenkins-based pipelines scan GitHub Enterprise repositories for changes, running Terragrunt plans or applies based on the branch. Internet connectivity is restricted; access to specific corporate network locations requires a request to the network services team. The pipelines are continuously being improved for robustness and security, including pre-commit checks and Fortify scans.
|
||||
|
||||
|
||||
---
|
||||
|
||||
## 关键概念
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 行动项
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 相关视频
|
||||
|
||||
> 配对视频笔记链接（生成后填入）
|
||||
|
||||
---
|
||||
|
||||
*最后更新: 2026-04-14*
|
||||
---
|
||||
title: CTP Topic 25 Labs Landing Zone overview - ITOM teams
|
||||
type: cloud-learning
|
||||
source-type: video
|
||||
category: DevOps & SRE/01_AWS-Landing-Zone
|
||||
tags:
|
||||
- AWS
|
||||
- Landing-Zone
|
||||
- Labs
|
||||
- ITOM
|
||||
- CTP
|
||||
date-added: 2026-04-14
|
||||
video-source: nas:///volume2/work/Public Cloud Learning Sessions/CTP _ Topic 25_ Labs Landing Zone overview - ITOM teams.mp4
|
||||
audio-source: ""
|
||||
status: summarized (Gemini 摘要)
|
||||
---
|
||||
|
||||
# CTP Topic 25 Labs Landing Zone overview - ITOM teams
|
||||
|
||||
**Source:** NAS `/volume2/work/Public Cloud Learning Sessions/CTP _ Topic 25_ Labs Landing Zone overview - ITOM teams.mp4`
|
||||
|
||||
**Type:** VIDEO | **Category:** 01_AWS-Landing-Zone
|
||||
|
||||
**Status:** 🟡 Awaiting Whisper transcription → Summary
|
||||
|
||||
---
|
||||
|
||||
## 摘要
|
||||
|
||||
> ## Labs Landing Zone Overview
|
||||
|
||||
The Labs landing zone is based on the Gruntworks reference architecture and AWS standards, utilizing a multi-account strategy. The entire stack is managed through infrastructure as code (Terraform), using a library of common functions accessible for review and modification. *Everything should be managed using Terraform or some other code-based mechanism.*
|
||||
|
||||
Key components include:
|
||||
|
||||
* **Shared Account:** Hosts the Jenkins master for the CI/CD pipeline (Gruntworks production grade), hardened AMIs, and a Docker container store.
|
||||
* **Logs Account:** Secure storage for AWS Config and CloudTrail logs, with access controlled by the security team.
|
||||
* **Security Account:** Manages user accounts and access, primarily for cross-account access and shared accounts, with most access being federated.
|
||||
* **Core Accounts:**
|
||||
* Active Directory: Manages Windows instances and IDPs (all in Swimford.net).
|
||||
* DNS: Manages AWS Swimford.net, allowing for local domains or referencing the wider infrastructure.
|
||||
* **Network Account:** Central hub for network communication, managing traffic via Transit Gateway and JetPult firewall. All internet access is routed through here, managed by the network team via tags. Pulse VPN access is also managed here, providing access to the micro focus network.
|
||||
* **Shared Service Accounts:** Provide access to services like monitoring (45 arc site) and Qualys.
|
||||
* **Product Account:** The primary working environment, built to standard infrastructure-as-code modules. It can have multiple accounts (production, staging, development). Logs are shipped to the logs account, and Jenkins manages automation within the account.
|
||||
|
||||
When deploying a product account, key requirements include defining IP address ranges and agreeing on specific tags with the network team for firewall access. *Access through that firewall is all managed by tags.* The team recommends using their Terraform modules for deploying subnets.
|
||||
|
||||
The standard Jenkins-based pipelines scan GitHub Enterprise repositories for changes, running Terragrunt plans or applies based on the branch. Internet connectivity is restricted; access to specific corporate network locations requires a request to the network services team. The pipelines are continuously being improved for robustness and security, including pre-commit checks and Fortify scans.
|
||||
|
||||
|
||||
---
|
||||
|
||||
## 关键概念
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 行动项
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 相关视频
|
||||
|
||||
> 配对视频笔记链接（生成后填入）
|
||||
|
||||
---
|
||||
|
||||
*最后更新: 2026-04-14*
|
||||
|
||||
@@ -1,52 +1,52 @@
|
||||
---
|
||||
title: CTP Topic 25 Labs Landing Zone overview - ITOM teams
|
||||
type: cloud-learning
|
||||
source-type: video
|
||||
category: DevOps & SRE/01_AWS-Landing-Zone
|
||||
tags:
|
||||
- AWS
|
||||
- Landing-Zone
|
||||
- Labs
|
||||
- ITOM
|
||||
- CTP
|
||||
date-added: 2026-04-14
|
||||
video-source: nas:///volume2/work/Public Cloud Learning Sessions/CTP _ Topic 25_ Labs Landing Zone overview - ITOM teams.mp4
|
||||
audio-source: ""
|
||||
status: raw
|
||||
---
|
||||
|
||||
# CTP Topic 25 Labs Landing Zone overview - ITOM teams
|
||||
|
||||
**Source:** NAS `/volume2/work/Public Cloud Learning Sessions/CTP _ Topic 25_ Labs Landing Zone overview - ITOM teams.mp4`
|
||||
|
||||
**Type:** VIDEO | **Category:** 01_AWS-Landing-Zone
|
||||
|
||||
**Status:** 🟡 Awaiting Whisper transcription → Summary
|
||||
|
||||
---
|
||||
|
||||
## 摘要
|
||||
|
||||
> 待转录后由 LLM 生成
|
||||
|
||||
---
|
||||
|
||||
## 关键概念
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 行动项
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 相关视频
|
||||
|
||||
> 配对视频笔记链接（生成后填入）
|
||||
|
||||
---
|
||||
|
||||
*最后更新: 2026-04-14*
|
||||
---
|
||||
title: CTP Topic 25 Labs Landing Zone overview - ITOM teams
|
||||
type: cloud-learning
|
||||
source-type: video
|
||||
category: DevOps & SRE/01_AWS-Landing-Zone
|
||||
tags:
|
||||
- AWS
|
||||
- Landing-Zone
|
||||
- Labs
|
||||
- ITOM
|
||||
- CTP
|
||||
date-added: 2026-04-14
|
||||
video-source: nas:///volume2/work/Public Cloud Learning Sessions/CTP _ Topic 25_ Labs Landing Zone overview - ITOM teams.mp4
|
||||
audio-source: ""
|
||||
status: raw
|
||||
---
|
||||
|
||||
# CTP Topic 25 Labs Landing Zone overview - ITOM teams
|
||||
|
||||
**Source:** NAS `/volume2/work/Public Cloud Learning Sessions/CTP _ Topic 25_ Labs Landing Zone overview - ITOM teams.mp4`
|
||||
|
||||
**Type:** VIDEO | **Category:** 01_AWS-Landing-Zone
|
||||
|
||||
**Status:** 🟡 Awaiting Whisper transcription → Summary
|
||||
|
||||
---
|
||||
|
||||
## 摘要
|
||||
|
||||
> 待转录后由 LLM 生成
|
||||
|
||||
---
|
||||
|
||||
## 关键概念
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 行动项
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 相关视频
|
||||
|
||||
> 配对视频笔记链接（生成后填入）
|
||||
|
||||
---
|
||||
|
||||
*最后更新: 2026-04-14*
|
||||
|
||||
@@ -1,64 +1,64 @@
|
||||
---
|
||||
title: "CTP Topic 26 Standard AMI – build, publish, share processes"
|
||||
type: cloud-learning
|
||||
source-type: video
|
||||
category: "DevOps & SRE/01_AWS-Landing-Zone"
|
||||
tags:
|
||||
- AWS
|
||||
- AMI
|
||||
- Build-Process
|
||||
- CTP
|
||||
date-added: 2026-04-14
|
||||
video-source: "nas:///volume2/work/Public Cloud Learning Sessions/CTP _ Topic 26_ Standard AMI – build, publish, share processes.mp4"
|
||||
audio-source: ""
|
||||
status: summarized (Gemini 摘要)
|
||||
---
|
||||
|
||||
# CTP Topic 26 Standard AMI – build, publish, share processes
|
||||
|
||||
**Source:** NAS `/volume2/work/Public Cloud Learning Sessions/CTP _ Topic 26_ Standard AMI – build, publish, share processes.mp4`
|
||||
|
||||
**Type:** VIDEO | **Category:** 01_AWS-Landing-Zone
|
||||
|
||||
**Status:** ✅ 已完成（Gemini 摘要）
|
||||
|
||||
---
|
||||
|
||||
## 摘要
|
||||
|
||||
> 本次会议是每周转型计划（Weekly Transformation Program）的一部分，重点讨论了 **Foundation AMI（基础亚马逊机器镜像）** 的构建、加固与分发流程。会议由 Srihari、Alan 和 Praveen 三位专家主讲，旨在向产品团队介绍如何利用标准化的镜像来提升安全性和运维效率。
|
||||
>
|
||||
> 核心内容涵盖了 Foundation AMI 的全生命周期管理。首先，Foundation AMI 是基于市场主流操作系统（如 CentOS, Ubuntu, Windows 等）进行深度加固的镜像，集成了 CIS 安全基准、防病毒软件（McAfee EPO）、日志管理（Syslog-ng）以及单点登录（AD 集成）。其主要优势在于“即插即用”，确保所有实例从启动之日起就符合 Micro Focus 的安全合规标准，并预装了 SSM Agent 和 SiteScope 监控预选件。
|
||||
>
|
||||
> 在技术实现上，团队采用了 **HashiCorp Packer** 和 **Jenkins** 构建流水线，实现了镜像创建的完全自动化。为了优化成本和分发速度，镜像存储在中央存储库中，并通过跨账号共享（Sharing）而非物理复制（Copying）的方式分发到全球多个区域（如俄勒冈、法兰克福、悉尼等）。此外，镜像每两个月更新一次，遵循 N-2 的版本保留策略。
|
||||
>
|
||||
> 最后，会议强调了责任共担模型：CCOE 负责提供安全的基础镜像，而产品团队则被鼓励在 Foundation AMI 之上构建自定义的“产品特定 AMI”，以满足各自应用的特殊需求，并负责其后续的生命周期管理。
|
||||
|
||||
---
|
||||
|
||||
## 关键概念
|
||||
|
||||
- **Foundation AMI**: 基础机器镜像，是经过安全加固、集成标准组件并预配置好的操作系统模板。
|
||||
- **OS Hardening**: 操作系统加固，通过关闭不必要服务、优化内核参数和应用安全补丁来减少系统攻击面。
|
||||
- **CIS Benchmarks**: 由互联网安全中心制定的安全配置基准，用于衡量镜像是否符合行业最佳安全实践。
|
||||
- **HashiCorp Packer**: 一种开源工具，用于从单一源配置为多个云平台自动创建一致的机器镜像。
|
||||
- **SSM Agent**: AWS 系统管理器代理，用于实现实例的远程管理、自动化补丁更新和配置同步。
|
||||
- **AMI Sharing**: 镜像共享机制，通过授权其他账号访问中央镜像，避免了跨账号复制带来的额外存储成本。
|
||||
- **Central Repository**: 中央仓库，用于统一存放和管理经过验证的官方镜像，确保分发源的唯一性。
|
||||
|
||||
---
|
||||
|
||||
## 相关视频
|
||||
|
||||
> [!info]+ 交叉引用
|
||||
> [[Cloud Transformation Program Overview]] — 了解转型计划的背景与整体框架
|
||||
> [[Guardrail Rules and Compliance]] — 关联 Foundation AMI 在合规性检查中的角色
|
||||
> [[CCOE Portal User Guide]] — 如何在门户网站订阅 AMI 更新通知
|
||||
|
||||
## 相关视频
|
||||
|
||||
> 配对视频笔记链接（生成后填入）
|
||||
|
||||
---
|
||||
|
||||
*最后更新: 2026-04-14*
|
||||
---
|
||||
title: "CTP Topic 26 Standard AMI – build, publish, share processes"
|
||||
type: cloud-learning
|
||||
source-type: video
|
||||
category: "DevOps & SRE/01_AWS-Landing-Zone"
|
||||
tags:
|
||||
- AWS
|
||||
- AMI
|
||||
- Build-Process
|
||||
- CTP
|
||||
date-added: 2026-04-14
|
||||
video-source: "nas:///volume2/work/Public Cloud Learning Sessions/CTP _ Topic 26_ Standard AMI – build, publish, share processes.mp4"
|
||||
audio-source: ""
|
||||
status: summarized (Gemini 摘要)
|
||||
---
|
||||
|
||||
# CTP Topic 26 Standard AMI – build, publish, share processes
|
||||
|
||||
**Source:** NAS `/volume2/work/Public Cloud Learning Sessions/CTP _ Topic 26_ Standard AMI – build, publish, share processes.mp4`
|
||||
|
||||
**Type:** VIDEO | **Category:** 01_AWS-Landing-Zone
|
||||
|
||||
**Status:** ✅ 已完成（Gemini 摘要）
|
||||
|
||||
---
|
||||
|
||||
## 摘要
|
||||
|
||||
> 本次会议是每周转型计划（Weekly Transformation Program）的一部分，重点讨论了 **Foundation AMI（基础亚马逊机器镜像）** 的构建、加固与分发流程。会议由 Srihari、Alan 和 Praveen 三位专家主讲，旨在向产品团队介绍如何利用标准化的镜像来提升安全性和运维效率。
|
||||
>
|
||||
> 核心内容涵盖了 Foundation AMI 的全生命周期管理。首先，Foundation AMI 是基于市场主流操作系统（如 CentOS, Ubuntu, Windows 等）进行深度加固的镜像，集成了 CIS 安全基准、防病毒软件（McAfee EPO）、日志管理（Syslog-ng）以及单点登录（AD 集成）。其主要优势在于“即插即用”，确保所有实例从启动之日起就符合 Micro Focus 的安全合规标准，并预装了 SSM Agent 和 SiteScope 监控预选件。
|
||||
>
|
||||
> 在技术实现上，团队采用了 **HashiCorp Packer** 和 **Jenkins** 构建流水线，实现了镜像创建的完全自动化。为了优化成本和分发速度，镜像存储在中央存储库中，并通过跨账号共享（Sharing）而非物理复制（Copying）的方式分发到全球多个区域（如俄勒冈、法兰克福、悉尼等）。此外，镜像每两个月更新一次，遵循 N-2 的版本保留策略。
|
||||
>
|
||||
> 最后，会议强调了责任共担模型：CCOE 负责提供安全的基础镜像，而产品团队则被鼓励在 Foundation AMI 之上构建自定义的“产品特定 AMI”，以满足各自应用的特殊需求，并负责其后续的生命周期管理。
|
||||
|
||||
---
|
||||
|
||||
## 关键概念
|
||||
|
||||
- **Foundation AMI**: 基础机器镜像，是经过安全加固、集成标准组件并预配置好的操作系统模板。
|
||||
- **OS Hardening**: 操作系统加固，通过关闭不必要服务、优化内核参数和应用安全补丁来减少系统攻击面。
|
||||
- **CIS Benchmarks**: 由互联网安全中心制定的安全配置基准，用于衡量镜像是否符合行业最佳安全实践。
|
||||
- **HashiCorp Packer**: 一种开源工具，用于从单一源配置为多个云平台自动创建一致的机器镜像。
|
||||
- **SSM Agent**: AWS 系统管理器代理，用于实现实例的远程管理、自动化补丁更新和配置同步。
|
||||
- **AMI Sharing**: 镜像共享机制，通过授权其他账号访问中央镜像，避免了跨账号复制带来的额外存储成本。
|
||||
- **Central Repository**: 中央仓库，用于统一存放和管理经过验证的官方镜像，确保分发源的唯一性。
|
||||
|
||||
---
|
||||
|
||||
## 相关视频
|
||||
|
||||
> [!info]+ 交叉引用
|
||||
> [[Cloud Transformation Program Overview]] — 了解转型计划的背景与整体框架
|
||||
> [[Guardrail Rules and Compliance]] — 关联 Foundation AMI 在合规性检查中的角色
|
||||
> [[CCOE Portal User Guide]] — 如何在门户网站订阅 AMI 更新通知
|
||||
|
||||
## 相关视频
|
||||
|
||||
> 配对视频笔记链接（生成后填入）
|
||||
|
||||
---
|
||||
|
||||
*最后更新: 2026-04-14*
|
||||
|
||||
@@ -1,62 +1,62 @@
|
||||
---
|
||||
title: "CTP Topic 28 AWS Tag Validation Tool"
|
||||
type: cloud-learning
|
||||
source-type: video
|
||||
category: "DevOps & SRE/01_AWS-Landing-Zone"
|
||||
tags:
|
||||
- AWS
|
||||
- Tagging
|
||||
- Validation
|
||||
- Tool
|
||||
- CTP
|
||||
date-added: 2026-04-14
|
||||
video-source: "nas:///volume2/work/Public Cloud Learning Sessions/CTP _ Topic 28_ AWS Tag Validation Tool.mp4"
|
||||
audio-source: ""
|
||||
status: summarized (Gemini 摘要)
|
||||
---
|
||||
|
||||
# CTP Topic 28 AWS Tag Validation Tool
|
||||
|
||||
**Source:** NAS `/volume2/work/Public Cloud Learning Sessions/CTP _ Topic 28_ AWS Tag Validation Tool.mp4`
|
||||
|
||||
**Type:** VIDEO | **Category:** 01_AWS-Landing-Zone
|
||||
|
||||
**Status:** ✅ 已完成（Gemini 摘要）
|
||||
|
||||
---
|
||||
|
||||
## 摘要
|
||||
|
||||
> 本次视频由 Lewis Brown 主讲，重点介绍了由 SRE 团队开发的一款 **AWS 标签验证工具（AWS Tag Validation Tool）**。在 AWS 架构中，标签（Tags）不仅是简单的元数据（键值对），还直接影响网络安全。该组织使用的 Checkpoint 防火墙会读取 EC2 实例、安全组和负载均衡器的标签值来配置网络访问权限；如果标签无效或缺失，防火墙将拦截相关网络流量。
|
||||
>
|
||||
> 虽然目前已通过服务控制策略（SCPs）在组织层面拦截了不合规资源的创建（目前主要应用于 SAS 账户），但对于大量已经存在的存量资源，仍需有效的审计手段。为此，Lewis 展示了这款基于 Python 和 Boto3 开发的工具。该工具通过读取包含各账户预定义合法标签值的 YAML 配置文件，自动扫描指定账户内的 EC2、安全组、负载均衡器及 Lambda 函数，并将扫描结果与预期值进行比对。
|
||||
>
|
||||
> 工具最终会生成一份详尽的 CSV 报告，列出所有缺失或标签值错误的资源 ID 及其具体问题，极大提高了审计效率。在演示环节，Lewis 展示了如何通过 Poetry 管理 Python 环境并运行该脚本。此外，视频还讨论了标签在未来成本核算（Costing）中的潜在用途，即通过标签区分同一账户下不同产品的资源消耗。
|
||||
|
||||
---
|
||||
|
||||
## 关键概念
|
||||
|
||||
- **AWS Tags**: 附加在 AWS 资源上的元数据，以键值对（Key-Value pairs）形式存在，用于识别和管理资源。
|
||||
- **Checkpoint Firewall**: 一种网络安全解决方案，在本案例中通过读取资源标签来动态配置和执行网络访问策略。
|
||||
- **Service Control Policies (SCPs)**: AWS Organizations 的一种策略，用于集中管理组织中所有账户的最大可用权限，此处用于强制执行标签规范。
|
||||
- **Boto3**: 适用于 Python 的 AWS SDK，允许开发者通过编写 Python 代码来调用 AWS 服务接口。
|
||||
- **Poetry**: 一个 Python 依赖管理和打包工具，用于确保开发环境的一致性并简化工具的安装与运行。
|
||||
- **variables.yaml**: 该工具的核心配置文件，定义了特定 AWS 账户所期望的合法标签键及其对应的允许值列表。
|
||||
- **SRE Tools Repository**: 存放该验证工具及其他 SRE 自动化脚本的内部代码仓库。
|
||||
|
||||
---
|
||||
|
||||
## 相关视频
|
||||
|
||||
> [!info]+ 交叉引用
|
||||
> [[CTP Topic 10 - AWS Tagging Deep Dive]] — 演讲者提到的相关视频，详细介绍了标签的技术细节与标准。
|
||||
> [[AWS Landing Zone Governance]] — 关联原因：讨论了新旧登陆区（Landing Zone）中通过标签进行治理的背景。
|
||||
|
||||
## 相关视频
|
||||
|
||||
> 配对视频笔记链接（生成后填入）
|
||||
|
||||
---
|
||||
|
||||
*最后更新: 2026-04-14*
|
||||
---
|
||||
title: "CTP Topic 28 AWS Tag Validation Tool"
|
||||
type: cloud-learning
|
||||
source-type: video
|
||||
category: "DevOps & SRE/01_AWS-Landing-Zone"
|
||||
tags:
|
||||
- AWS
|
||||
- Tagging
|
||||
- Validation
|
||||
- Tool
|
||||
- CTP
|
||||
date-added: 2026-04-14
|
||||
video-source: "nas:///volume2/work/Public Cloud Learning Sessions/CTP _ Topic 28_ AWS Tag Validation Tool.mp4"
|
||||
audio-source: ""
|
||||
status: summarized (Gemini 摘要)
|
||||
---
|
||||
|
||||
# CTP Topic 28 AWS Tag Validation Tool
|
||||
|
||||
**Source:** NAS `/volume2/work/Public Cloud Learning Sessions/CTP _ Topic 28_ AWS Tag Validation Tool.mp4`
|
||||
|
||||
**Type:** VIDEO | **Category:** 01_AWS-Landing-Zone
|
||||
|
||||
**Status:** ✅ 已完成（Gemini 摘要）
|
||||
|
||||
---
|
||||
|
||||
## 摘要
|
||||
|
||||
> 本次视频由 Lewis Brown 主讲，重点介绍了由 SRE 团队开发的一款 **AWS 标签验证工具（AWS Tag Validation Tool）**。在 AWS 架构中，标签（Tags）不仅是简单的元数据（键值对），还直接影响网络安全。该组织使用的 Checkpoint 防火墙会读取 EC2 实例、安全组和负载均衡器的标签值来配置网络访问权限；如果标签无效或缺失，防火墙将拦截相关网络流量。
|
||||
>
|
||||
> 虽然目前已通过服务控制策略（SCPs）在组织层面拦截了不合规资源的创建（目前主要应用于 SAS 账户），但对于大量已经存在的存量资源，仍需有效的审计手段。为此，Lewis 展示了这款基于 Python 和 Boto3 开发的工具。该工具通过读取包含各账户预定义合法标签值的 YAML 配置文件，自动扫描指定账户内的 EC2、安全组、负载均衡器及 Lambda 函数，并将扫描结果与预期值进行比对。
|
||||
>
|
||||
> 工具最终会生成一份详尽的 CSV 报告，列出所有缺失或标签值错误的资源 ID 及其具体问题，极大提高了审计效率。在演示环节，Lewis 展示了如何通过 Poetry 管理 Python 环境并运行该脚本。此外，视频还讨论了标签在未来成本核算（Costing）中的潜在用途，即通过标签区分同一账户下不同产品的资源消耗。
|
||||
|
||||
---
|
||||
|
||||
## 关键概念
|
||||
|
||||
- **AWS Tags**: 附加在 AWS 资源上的元数据，以键值对（Key-Value pairs）形式存在，用于识别和管理资源。
|
||||
- **Checkpoint Firewall**: 一种网络安全解决方案，在本案例中通过读取资源标签来动态配置和执行网络访问策略。
|
||||
- **Service Control Policies (SCPs)**: AWS Organizations 的一种策略，用于集中管理组织中所有账户的最大可用权限，此处用于强制执行标签规范。
|
||||
- **Boto3**: 适用于 Python 的 AWS SDK，允许开发者通过编写 Python 代码来调用 AWS 服务接口。
|
||||
- **Poetry**: 一个 Python 依赖管理和打包工具，用于确保开发环境的一致性并简化工具的安装与运行。
|
||||
- **variables.yaml**: 该工具的核心配置文件，定义了特定 AWS 账户所期望的合法标签键及其对应的允许值列表。
|
||||
- **SRE Tools Repository**: 存放该验证工具及其他 SRE 自动化脚本的内部代码仓库。
|
||||
|
||||
---
|
||||
|
||||
## 相关视频
|
||||
|
||||
> [!info]+ 交叉引用
|
||||
> [[CTP Topic 10 - AWS Tagging Deep Dive]] — 演讲者提到的相关视频，详细介绍了标签的技术细节与标准。
|
||||
> [[AWS Landing Zone Governance]] — 关联原因：讨论了新旧登陆区（Landing Zone）中通过标签进行治理的背景。
|
||||
|
||||
## 相关视频
|
||||
|
||||
> 配对视频笔记链接（生成后填入）
|
||||
|
||||
---
|
||||
|
||||
*最后更新: 2026-04-14*
|
||||
|
||||
@@ -1,59 +1,59 @@
|
||||
---
|
||||
title: CTP Topic 34 Azure Landing Zone Architecture Overview
|
||||
type: cloud-learning
|
||||
source-type: video
|
||||
category: DevOps & SRE/01_AWS-Landing-Zone
|
||||
tags:
|
||||
- Azure
|
||||
- Landing-Zone
|
||||
- CTP
|
||||
date-added: 2026-04-14
|
||||
video-source: nas:///volume2/work/Public Cloud Learning Sessions/CTP _ Topic 34_ Azure Landing Zone Architecture Overview.mp4
|
||||
audio-source: ""
|
||||
status: summarized (Gemini 摘要)
|
||||
---
|
||||
|
||||
# CTP Topic 34 Azure Landing Zone Architecture Overview
|
||||
|
||||
**Source:** NAS `/volume2/work/Public Cloud Learning Sessions/CTP _ Topic 34_ Azure Landing Zone Architecture Overview.mp4`
|
||||
|
||||
**Type:** VIDEO | **Category:** 01_AWS-Landing-Zone
|
||||
|
||||
**Status:** 🟡 Awaiting Whisper transcription → Summary
|
||||
|
||||
---
|
||||
|
||||
## 摘要
|
||||
|
||||
> ## Azure Landing Zone Architecture Overview
|
||||
|
||||
Kishore Garlopati presents an overview of the upcoming Azure Landing Zones implementation within Micro Focus, detailing how it will simplify Azure adoption for various teams and enable them to deploy workloads to the Azure cloud. The primary goal is to minimize cross-team dependencies through automation, granting teams greater independence in deploying innovative solutions within the Azure environment.
|
||||
|
||||
The architecture begins with enrollment into Azure Enterprise, utilizing Azure Active Directory for user authentication. Azure employs management groups, similar to parent directories in Windows, to organize the entities within Micro Focus. These are divided into four areas: platform, landing zones, decommission, and sandbox. The platform includes identity management and connectivity subscriptions, each with a specific purpose and managed by dedicated teams to enhance security. *The core reason of these individual or isolated subscriptions is you are basically containing a subscription for a specific purpose.*
|
||||
|
||||
Identity subscriptions manage access policies, while connectivity subscriptions serve as a central hub for all inbound and outbound Azure traffic, incorporating security measures like DDoS protection and checkpoint firewalls. Landing zones are designed to be scalable, modular, and fully automated, providing a template-based approach for new projects. These zones emphasize identity access management, auditing, compliance, security monitoring, and networking. Decommissioned subscriptions are for unused resources, and sandbox subscriptions offer isolated environments for experimentation. *This sandbox is a is an interesting one because these landings on subscriptions allows your workloads.*
|
||||
|
||||
Privileged Identity Management (PIM) and privileged access groups manage user access, ensuring appropriate role and policy enforcement. Terraform Cloud is used for infrastructure automation, leveraging Terraform states to manage dependencies between subscriptions. This layered approach allows teams to access necessary data without exposing sensitive information.
|
||||
|
||||
|
||||
---
|
||||
|
||||
## 关键概念
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 行动项
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 相关视频
|
||||
|
||||
> 配对视频笔记链接（生成后填入）
|
||||
|
||||
---
|
||||
|
||||
*最后更新: 2026-04-14*
|
||||
---
|
||||
title: CTP Topic 34 Azure Landing Zone Architecture Overview
|
||||
type: cloud-learning
|
||||
source-type: video
|
||||
category: DevOps & SRE/01_AWS-Landing-Zone
|
||||
tags:
|
||||
- Azure
|
||||
- Landing-Zone
|
||||
- CTP
|
||||
date-added: 2026-04-14
|
||||
video-source: nas:///volume2/work/Public Cloud Learning Sessions/CTP _ Topic 34_ Azure Landing Zone Architecture Overview.mp4
|
||||
audio-source: ""
|
||||
status: summarized (Gemini 摘要)
|
||||
---
|
||||
|
||||
# CTP Topic 34 Azure Landing Zone Architecture Overview
|
||||
|
||||
**Source:** NAS `/volume2/work/Public Cloud Learning Sessions/CTP _ Topic 34_ Azure Landing Zone Architecture Overview.mp4`
|
||||
|
||||
**Type:** VIDEO | **Category:** 01_AWS-Landing-Zone
|
||||
|
||||
**Status:** 🟡 Awaiting Whisper transcription → Summary
|
||||
|
||||
---
|
||||
|
||||
## 摘要
|
||||
|
||||
> ## Azure Landing Zone Architecture Overview
|
||||
|
||||
Kishore Garlopati presents an overview of the upcoming Azure Landing Zones implementation within Micro Focus, detailing how it will simplify Azure adoption for various teams and enable them to deploy workloads to the Azure cloud. The primary goal is to minimize cross-team dependencies through automation, granting teams greater independence in deploying innovative solutions within the Azure environment.
|
||||
|
||||
The architecture begins with enrollment into Azure Enterprise, utilizing Azure Active Directory for user authentication. Azure employs management groups, similar to parent directories in Windows, to organize the entities within Micro Focus. These are divided into four areas: platform, landing zones, decommission, and sandbox. The platform includes identity management and connectivity subscriptions, each with a specific purpose and managed by dedicated teams to enhance security. *The core reason of these individual or isolated subscriptions is you are basically containing a subscription for a specific purpose.*
|
||||
|
||||
Identity subscriptions manage access policies, while connectivity subscriptions serve as a central hub for all inbound and outbound Azure traffic, incorporating security measures like DDoS protection and checkpoint firewalls. Landing zones are designed to be scalable, modular, and fully automated, providing a template-based approach for new projects. These zones emphasize identity access management, auditing, compliance, security monitoring, and networking. Decommissioned subscriptions are for unused resources, and sandbox subscriptions offer isolated environments for experimentation. *This sandbox is a is an interesting one because these landings on subscriptions allows your workloads.*
|
||||
|
||||
Privileged Identity Management (PIM) and privileged access groups manage user access, ensuring appropriate role and policy enforcement. Terraform Cloud is used for infrastructure automation, leveraging Terraform states to manage dependencies between subscriptions. This layered approach allows teams to access necessary data without exposing sensitive information.
|
||||
|
||||
|
||||
---
|
||||
|
||||
## 关键概念
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 行动项
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 相关视频
|
||||
|
||||
> 配对视频笔记链接（生成后填入）
|
||||
|
||||
---
|
||||
|
||||
*最后更新: 2026-04-14*
|
||||
|
||||
@@ -1,50 +1,50 @@
|
||||
---
|
||||
title: CTP Topic 34 Azure Landing Zone Architecture Overview
|
||||
type: cloud-learning
|
||||
source-type: video
|
||||
category: DevOps & SRE/01_AWS-Landing-Zone
|
||||
tags:
|
||||
- Azure
|
||||
- Landing-Zone
|
||||
- CTP
|
||||
date-added: 2026-04-14
|
||||
video-source: nas:///volume2/work/Public Cloud Learning Sessions/CTP _ Topic 34_ Azure Landing Zone Architecture Overview.mp4
|
||||
audio-source: ""
|
||||
status: raw
|
||||
---
|
||||
|
||||
# CTP Topic 34 Azure Landing Zone Architecture Overview
|
||||
|
||||
**Source:** NAS `/volume2/work/Public Cloud Learning Sessions/CTP _ Topic 34_ Azure Landing Zone Architecture Overview.mp4`
|
||||
|
||||
**Type:** VIDEO | **Category:** 01_AWS-Landing-Zone
|
||||
|
||||
**Status:** 🟡 Awaiting Whisper transcription → Summary
|
||||
|
||||
---
|
||||
|
||||
## 摘要
|
||||
|
||||
> 待转录后由 LLM 生成
|
||||
|
||||
---
|
||||
|
||||
## 关键概念
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 行动项
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 相关视频
|
||||
|
||||
> 配对视频笔记链接（生成后填入）
|
||||
|
||||
---
|
||||
|
||||
*最后更新: 2026-04-14*
|
||||
---
|
||||
title: CTP Topic 34 Azure Landing Zone Architecture Overview
|
||||
type: cloud-learning
|
||||
source-type: video
|
||||
category: DevOps & SRE/01_AWS-Landing-Zone
|
||||
tags:
|
||||
- Azure
|
||||
- Landing-Zone
|
||||
- CTP
|
||||
date-added: 2026-04-14
|
||||
video-source: nas:///volume2/work/Public Cloud Learning Sessions/CTP _ Topic 34_ Azure Landing Zone Architecture Overview.mp4
|
||||
audio-source: ""
|
||||
status: raw
|
||||
---
|
||||
|
||||
# CTP Topic 34 Azure Landing Zone Architecture Overview
|
||||
|
||||
**Source:** NAS `/volume2/work/Public Cloud Learning Sessions/CTP _ Topic 34_ Azure Landing Zone Architecture Overview.mp4`
|
||||
|
||||
**Type:** VIDEO | **Category:** 01_AWS-Landing-Zone
|
||||
|
||||
**Status:** 🟡 Awaiting Whisper transcription → Summary
|
||||
|
||||
---
|
||||
|
||||
## 摘要
|
||||
|
||||
> 待转录后由 LLM 生成
|
||||
|
||||
---
|
||||
|
||||
## 关键概念
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 行动项
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 相关视频
|
||||
|
||||
> 配对视频笔记链接（生成后填入）
|
||||
|
||||
---
|
||||
|
||||
*最后更新: 2026-04-14*
|
||||
|
||||
@@ -1,59 +1,59 @@
|
||||
---
|
||||
title: CTP Topic 35 AWS Landing Zone Design Refresher (SaaS Labs)
|
||||
type: cloud-learning
|
||||
source-type: video
|
||||
category: DevOps & SRE/01_AWS-Landing-Zone
|
||||
tags:
|
||||
- AWS
|
||||
- Landing-Zone
|
||||
- SaaS
|
||||
- Labs
|
||||
- CTP
|
||||
date-added: 2026-04-14
|
||||
video-source: nas:///volume2/work/Public Cloud Learning Sessions/CTP _ Topic 35_ AWS Landing Zone Design Refresher (SaaS _ Labs).mp4
|
||||
audio-source: ""
|
||||
status: summarized (Gemini 摘要)
|
||||
---
|
||||
|
||||
# CTP Topic 35 AWS Landing Zone Design Refresher (SaaS Labs)
|
||||
|
||||
**Source:** NAS `/volume2/work/Public Cloud Learning Sessions/CTP _ Topic 35_ AWS Landing Zone Design Refresher (SaaS _ Labs).mp4`
|
||||
|
||||
**Type:** VIDEO | **Category:** 01_AWS-Landing-Zone
|
||||
|
||||
**Status:** 🟡 Awaiting Whisper transcription → Summary
|
||||
|
||||
---
|
||||
|
||||
## 摘要
|
||||
|
||||
> ## AWS Landing Zone Design Refresher
|
||||
|
||||
This session provides an overview of AWS Landing Zones, focusing on their design, updates, and differences between SaaS and Labs environments. The primary goal of landing zones is to support diverse AWS use cases while ensuring reuse, control, auditing, and management. *Our AWS landing zones, they're built infrastructure as code as you'd expect on terraform templates using the grunt work framework.*
|
||||
|
||||
AWS SaaS landing zones offer customer-dedicated environments with product accounts for each product area, such as Snacks. These accounts connect to shared services accounts for security, logging, and networking. The core accounts group includes Active Directory, DNS, and network accounts to support IT services within the micro-focus infrastructure. The shared service accounts host services like artifactory, cyberqualice, cyber EPO, ArcSight, and monitoring. Grunt work accounts manage AMIs, logs, and security across all accounts. Product accounts host IT products, projects, applications, and supporting AWS resources, managed by individual project teams.
|
||||
|
||||
Recent changes to the landing zones include network segmentation to block direct connectivity to SaaS workloads, decommissioning of the Gruntworks Cloud Trail in favor of CCOEs Cloud Trail, and proposed rerouting of ingress traffic via checkpoints in the network account. Native AWS backup is likely to be mandated, and management VPCs may be removed for new accounts. The key difference between SaaS and Labs is that SaaS is for production, while Labs is for development, with plans to introduce internet access into Labs. *Basically, the only answer is that SAS is production, Labs is development.* The PoC landing zone will be combined with Labs to maximize shared resources. The Cloud Technology Design Forum aims to standardize and centralize microfocus's cloud delivery offering, including landing zone designs.
|
||||
|
||||
|
||||
---
|
||||
|
||||
## 关键概念
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 行动项
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 相关视频
|
||||
|
||||
> 配对视频笔记链接（生成后填入）
|
||||
|
||||
---
|
||||
|
||||
*最后更新: 2026-04-14*
|
||||
---
|
||||
title: CTP Topic 35 AWS Landing Zone Design Refresher (SaaS Labs)
|
||||
type: cloud-learning
|
||||
source-type: video
|
||||
category: DevOps & SRE/01_AWS-Landing-Zone
|
||||
tags:
|
||||
- AWS
|
||||
- Landing-Zone
|
||||
- SaaS
|
||||
- Labs
|
||||
- CTP
|
||||
date-added: 2026-04-14
|
||||
video-source: nas:///volume2/work/Public Cloud Learning Sessions/CTP _ Topic 35_ AWS Landing Zone Design Refresher (SaaS _ Labs).mp4
|
||||
audio-source: ""
|
||||
status: summarized (Gemini 摘要)
|
||||
---
|
||||
|
||||
# CTP Topic 35 AWS Landing Zone Design Refresher (SaaS Labs)
|
||||
|
||||
**Source:** NAS `/volume2/work/Public Cloud Learning Sessions/CTP _ Topic 35_ AWS Landing Zone Design Refresher (SaaS _ Labs).mp4`
|
||||
|
||||
**Type:** VIDEO | **Category:** 01_AWS-Landing-Zone
|
||||
|
||||
**Status:** 🟡 Awaiting Whisper transcription → Summary
|
||||
|
||||
---
|
||||
|
||||
## 摘要
|
||||
|
||||
> ## AWS Landing Zone Design Refresher
|
||||
|
||||
This session provides an overview of AWS Landing Zones, focusing on their design, updates, and differences between SaaS and Labs environments. The primary goal of landing zones is to support diverse AWS use cases while ensuring reuse, control, auditing, and management. *Our AWS landing zones, they're built infrastructure as code as you'd expect on terraform templates using the grunt work framework.*
|
||||
|
||||
AWS SaaS landing zones offer customer-dedicated environments with product accounts for each product area, such as Snacks. These accounts connect to shared services accounts for security, logging, and networking. The core accounts group includes Active Directory, DNS, and network accounts to support IT services within the micro-focus infrastructure. The shared service accounts host services like artifactory, cyberqualice, cyber EPO, ArcSight, and monitoring. Grunt work accounts manage AMIs, logs, and security across all accounts. Product accounts host IT products, projects, applications, and supporting AWS resources, managed by individual project teams.
|
||||
|
||||
Recent changes to the landing zones include network segmentation to block direct connectivity to SaaS workloads, decommissioning of the Gruntworks Cloud Trail in favor of CCOEs Cloud Trail, and proposed rerouting of ingress traffic via checkpoints in the network account. Native AWS backup is likely to be mandated, and management VPCs may be removed for new accounts. The key difference between SaaS and Labs is that SaaS is for production, while Labs is for development, with plans to introduce internet access into Labs. *Basically, the only answer is that SAS is production, Labs is development.* The PoC landing zone will be combined with Labs to maximize shared resources. The Cloud Technology Design Forum aims to standardize and centralize microfocus's cloud delivery offering, including landing zone designs.
|
||||
|
||||
|
||||
---
|
||||
|
||||
## 关键概念
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 行动项
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 相关视频
|
||||
|
||||
> 配对视频笔记链接（生成后填入）
|
||||
|
||||
---
|
||||
|
||||
*最后更新: 2026-04-14*
|
||||
|
||||
@@ -1,52 +1,52 @@
|
||||
---
|
||||
title: CTP Topic 35 AWS Landing Zone Design Refresher (SaaS Labs)
|
||||
type: cloud-learning
|
||||
source-type: video
|
||||
category: DevOps & SRE/01_AWS-Landing-Zone
|
||||
tags:
|
||||
- AWS
|
||||
- Landing-Zone
|
||||
- SaaS
|
||||
- Labs
|
||||
- CTP
|
||||
date-added: 2026-04-14
|
||||
video-source: nas:///volume2/work/Public Cloud Learning Sessions/CTP _ Topic 35_ AWS Landing Zone Design Refresher (SaaS _ Labs).mp4
|
||||
audio-source: ""
|
||||
status: raw
|
||||
---
|
||||
|
||||
# CTP Topic 35 AWS Landing Zone Design Refresher (SaaS Labs)
|
||||
|
||||
**Source:** NAS `/volume2/work/Public Cloud Learning Sessions/CTP _ Topic 35_ AWS Landing Zone Design Refresher (SaaS _ Labs).mp4`
|
||||
|
||||
**Type:** VIDEO | **Category:** 01_AWS-Landing-Zone
|
||||
|
||||
**Status:** 🟡 Awaiting Whisper transcription → Summary
|
||||
|
||||
---
|
||||
|
||||
## 摘要
|
||||
|
||||
> 待转录后由 LLM 生成
|
||||
|
||||
---
|
||||
|
||||
## 关键概念
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 行动项
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 相关视频
|
||||
|
||||
> 配对视频笔记链接（生成后填入）
|
||||
|
||||
---
|
||||
|
||||
*最后更新: 2026-04-14*
|
||||
---
|
||||
title: CTP Topic 35 AWS Landing Zone Design Refresher (SaaS Labs)
|
||||
type: cloud-learning
|
||||
source-type: video
|
||||
category: DevOps & SRE/01_AWS-Landing-Zone
|
||||
tags:
|
||||
- AWS
|
||||
- Landing-Zone
|
||||
- SaaS
|
||||
- Labs
|
||||
- CTP
|
||||
date-added: 2026-04-14
|
||||
video-source: nas:///volume2/work/Public Cloud Learning Sessions/CTP _ Topic 35_ AWS Landing Zone Design Refresher (SaaS _ Labs).mp4
|
||||
audio-source: ""
|
||||
status: raw
|
||||
---
|
||||
|
||||
# CTP Topic 35 AWS Landing Zone Design Refresher (SaaS Labs)
|
||||
|
||||
**Source:** NAS `/volume2/work/Public Cloud Learning Sessions/CTP _ Topic 35_ AWS Landing Zone Design Refresher (SaaS _ Labs).mp4`
|
||||
|
||||
**Type:** VIDEO | **Category:** 01_AWS-Landing-Zone
|
||||
|
||||
**Status:** 🟡 Awaiting Whisper transcription → Summary
|
||||
|
||||
---
|
||||
|
||||
## 摘要
|
||||
|
||||
> 待转录后由 LLM 生成
|
||||
|
||||
---
|
||||
|
||||
## 关键概念
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 行动项
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 相关视频
|
||||
|
||||
> 配对视频笔记链接（生成后填入）
|
||||
|
||||
---
|
||||
|
||||
*最后更新: 2026-04-14*
|
||||
|
||||
@@ -1,63 +1,63 @@
|
||||
---
|
||||
title: CTP Topic 40 SaaS Database Architecture On AWS Cloud
|
||||
type: cloud-learning
|
||||
source-type: video
|
||||
category: DevOps & SRE/01_AWS-Landing-Zone
|
||||
tags:
|
||||
- SaaS
|
||||
- Database
|
||||
- Architecture
|
||||
- AWS
|
||||
- CTP
|
||||
date-added: 2026-04-14
|
||||
video-source: nas:///volume2/work/Public Cloud Learning Sessions/CTP _ Topic 40_ SaaS Database Architecture On AWS Cloud.mp4
|
||||
audio-source: ""
|
||||
status: summarized (Gemini 摘要)
|
||||
---
|
||||
|
||||
# CTP Topic 40 SaaS Database Architecture On AWS Cloud
|
||||
|
||||
**Source:** NAS `/volume2/work/Public Cloud Learning Sessions/CTP _ Topic 40_ SaaS Database Architecture On AWS Cloud.mp4`
|
||||
|
||||
**Type:** VIDEO | **Category:** 01_AWS-Landing-Zone
|
||||
|
||||
**Status:** 🟡 Awaiting Whisper transcription → Summary
|
||||
|
||||
---
|
||||
|
||||
## 摘要
|
||||
|
||||
> ## SAS Database Architecture on AWS Cloud
|
||||
|
||||
The SAS database team is a global team located in the US, Canada, India, and Israel, providing 24/7 support. The team consists of certified professionals, including Oracle certified professionals, DBAs, and security professionals. They manage over 500 databases and 1000+ DB servers on-premise and in the public cloud, having migrated numerous DB servers and databases to the public cloud.
|
||||
|
||||
The team supports various regions, including Sacramento and Reading for on-premise data centers, and AWS regions like Canada, Frankfurt, London, Oregon, North Virginia, and Sydney. They support database flavors such as Oracle, Vertica, Postgres, DynamoDB, SQL Server, MongoDB, and MySQL, utilizing AWS technologies like Postgres Aurora, Elasticsearch, AWS RDS, EFS, S3, and EBS. Databases reside mostly on application VPCs with integrated security measures.
|
||||
|
||||
For database monitoring, performance tuning, and gap analysis, tools like Micro Focus Sidescope, Oracle OEM, Ignite, AWS CloudWatch, and Questsoft Foglight are used. Day-to-day operations are managed through a ticketing tool, with an on-call DBA resource. The team actively participates in squads and executes a minimum of 10 changes a month, handling 400-500 SSRs and IMs monthly. They provide layer 1 and layer 3 support, using technologies like shell scripting, Terraform, AWS CLI, and PowerShell for automation. *Data center migrations and cloud provisioning were key automation projects.*
|
||||
|
||||
Key projects include data center migrations, onboarding new customers, database security enhancements, DB-AD integrations, SOX compliance, database consolidation, and DB patching. The team is also working on Oracle Golden Gate for multi-tenancy, adopting cloud-native technologies, and enhancing the Pretty Tool for on-demand backups and database migrations. Future plans involve new AMI automations, storage compression, RI instance optimization, AWS cloud-native backups, and enhancements to the DB apps tool. *The idea was to move those databases seamless without downtime or with minimum downtime.*
|
||||
|
||||
For high availability, Oracle uses Data Guard technology, Postgres uses a classic active-passive mechanism (with plans to use Active Active), and RDS uses RDS high availability. Databases are run in two availability zones within a region, with a primary database in one zone, a standby database in the second, and a witness in the third to observe and manage failovers. Reporting databases have a read-only warehouse in the third availability zone, with secure VPN access for customers to run operational warehousing queries.
|
||||
|
||||
|
||||
---
|
||||
|
||||
## 关键概念
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 行动项
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 相关视频
|
||||
|
||||
> 配对视频笔记链接（生成后填入）
|
||||
|
||||
---
|
||||
|
||||
*最后更新: 2026-04-14*
|
||||
---
|
||||
title: CTP Topic 40 SaaS Database Architecture On AWS Cloud
|
||||
type: cloud-learning
|
||||
source-type: video
|
||||
category: DevOps & SRE/01_AWS-Landing-Zone
|
||||
tags:
|
||||
- SaaS
|
||||
- Database
|
||||
- Architecture
|
||||
- AWS
|
||||
- CTP
|
||||
date-added: 2026-04-14
|
||||
video-source: nas:///volume2/work/Public Cloud Learning Sessions/CTP _ Topic 40_ SaaS Database Architecture On AWS Cloud.mp4
|
||||
audio-source: ""
|
||||
status: summarized (Gemini 摘要)
|
||||
---
|
||||
|
||||
# CTP Topic 40 SaaS Database Architecture On AWS Cloud
|
||||
|
||||
**Source:** NAS `/volume2/work/Public Cloud Learning Sessions/CTP _ Topic 40_ SaaS Database Architecture On AWS Cloud.mp4`
|
||||
|
||||
**Type:** VIDEO | **Category:** 01_AWS-Landing-Zone
|
||||
|
||||
**Status:** 🟡 Awaiting Whisper transcription → Summary
|
||||
|
||||
---
|
||||
|
||||
## 摘要
|
||||
|
||||
> ## SAS Database Architecture on AWS Cloud
|
||||
|
||||
The SAS database team is a global team located in the US, Canada, India, and Israel, providing 24/7 support. The team consists of certified professionals, including Oracle certified professionals, DBAs, and security professionals. They manage over 500 databases and 1000+ DB servers on-premise and in the public cloud, having migrated numerous DB servers and databases to the public cloud.
|
||||
|
||||
The team supports various regions, including Sacramento and Reading for on-premise data centers, and AWS regions like Canada, Frankfurt, London, Oregon, North Virginia, and Sydney. They support database flavors such as Oracle, Vertica, Postgres, DynamoDB, SQL Server, MongoDB, and MySQL, utilizing AWS technologies like Postgres Aurora, Elasticsearch, AWS RDS, EFS, S3, and EBS. Databases reside mostly on application VPCs with integrated security measures.
|
||||
|
||||
For database monitoring, performance tuning, and gap analysis, tools like Micro Focus Sidescope, Oracle OEM, Ignite, AWS CloudWatch, and Questsoft Foglight are used. Day-to-day operations are managed through a ticketing tool, with an on-call DBA resource. The team actively participates in squads and executes a minimum of 10 changes a month, handling 400-500 SSRs and IMs monthly. They provide layer 1 and layer 3 support, using technologies like shell scripting, Terraform, AWS CLI, and PowerShell for automation. *Data center migrations and cloud provisioning were key automation projects.*
|
||||
|
||||
Key projects include data center migrations, onboarding new customers, database security enhancements, DB-AD integrations, SOX compliance, database consolidation, and DB patching. The team is also working on Oracle Golden Gate for multi-tenancy, adopting cloud-native technologies, and enhancing the Pretty Tool for on-demand backups and database migrations. Future plans involve new AMI automations, storage compression, RI instance optimization, AWS cloud-native backups, and enhancements to the DB apps tool. *The idea was to move those databases seamless without downtime or with minimum downtime.*
|
||||
|
||||
For high availability, Oracle uses Data Guard technology, Postgres uses a classic active-passive mechanism (with plans to use Active Active), and RDS uses RDS high availability. Databases are run in two availability zones within a region, with a primary database in one zone, a standby database in the second, and a witness in the third to observe and manage failovers. Reporting databases have a read-only warehouse in the third availability zone, with secure VPN access for customers to run operational warehousing queries.
|
||||
|
||||
|
||||
---
|
||||
|
||||
## 关键概念
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 行动项
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 相关视频
|
||||
|
||||
> 配对视频笔记链接（生成后填入）
|
||||
|
||||
---
|
||||
|
||||
*最后更新: 2026-04-14*
|
||||
|
||||
@@ -1,52 +1,52 @@
|
||||
---
|
||||
title: CTP Topic 40 SaaS Database Architecture On AWS Cloud
|
||||
type: cloud-learning
|
||||
source-type: video
|
||||
category: DevOps & SRE/01_AWS-Landing-Zone
|
||||
tags:
|
||||
- SaaS
|
||||
- Database
|
||||
- Architecture
|
||||
- AWS
|
||||
- CTP
|
||||
date-added: 2026-04-14
|
||||
video-source: nas:///volume2/work/Public Cloud Learning Sessions/CTP _ Topic 40_ SaaS Database Architecture On AWS Cloud.mp4
|
||||
audio-source: ""
|
||||
status: raw
|
||||
---
|
||||
|
||||
# CTP Topic 40 SaaS Database Architecture On AWS Cloud
|
||||
|
||||
**Source:** NAS `/volume2/work/Public Cloud Learning Sessions/CTP _ Topic 40_ SaaS Database Architecture On AWS Cloud.mp4`
|
||||
|
||||
**Type:** VIDEO | **Category:** 01_AWS-Landing-Zone
|
||||
|
||||
**Status:** 🟡 Awaiting Whisper transcription → Summary
|
||||
|
||||
---
|
||||
|
||||
## 摘要
|
||||
|
||||
> 待转录后由 LLM 生成
|
||||
|
||||
---
|
||||
|
||||
## 关键概念
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 行动项
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 相关视频
|
||||
|
||||
> 配对视频笔记链接（生成后填入）
|
||||
|
||||
---
|
||||
|
||||
*最后更新: 2026-04-14*
|
||||
---
|
||||
title: CTP Topic 40 SaaS Database Architecture On AWS Cloud
|
||||
type: cloud-learning
|
||||
source-type: video
|
||||
category: DevOps & SRE/01_AWS-Landing-Zone
|
||||
tags:
|
||||
- SaaS
|
||||
- Database
|
||||
- Architecture
|
||||
- AWS
|
||||
- CTP
|
||||
date-added: 2026-04-14
|
||||
video-source: nas:///volume2/work/Public Cloud Learning Sessions/CTP _ Topic 40_ SaaS Database Architecture On AWS Cloud.mp4
|
||||
audio-source: ""
|
||||
status: raw
|
||||
---
|
||||
|
||||
# CTP Topic 40 SaaS Database Architecture On AWS Cloud
|
||||
|
||||
**Source:** NAS `/volume2/work/Public Cloud Learning Sessions/CTP _ Topic 40_ SaaS Database Architecture On AWS Cloud.mp4`
|
||||
|
||||
**Type:** VIDEO | **Category:** 01_AWS-Landing-Zone
|
||||
|
||||
**Status:** 🟡 Awaiting Whisper transcription → Summary
|
||||
|
||||
---
|
||||
|
||||
## 摘要
|
||||
|
||||
> 待转录后由 LLM 生成
|
||||
|
||||
---
|
||||
|
||||
## 关键概念
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 行动项
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 相关视频
|
||||
|
||||
> 配对视频笔记链接（生成后填入）
|
||||
|
||||
---
|
||||
|
||||
*最后更新: 2026-04-14*
|
||||
|
||||
@@ -1,87 +1,87 @@
|
||||
---
|
||||
title: "CTP Topic 44 AWS Backup in Micro Focus"
|
||||
type: cloud-learning
|
||||
source-type: video
|
||||
category: "DevOps & SRE/01_AWS-Landing-Zone"
|
||||
tags:
|
||||
- AWS
|
||||
- Backup
|
||||
- DR
|
||||
- CTP
|
||||
date-added: 2026-04-14
|
||||
video-source: "nas:///volume2/work/Public Cloud Learning Sessions/CTP _ Topic 44_ AWS Backup in Micro Focus.mp4"
|
||||
audio-source: ""
|
||||
status: summarized (Gemini 摘要)
|
||||
---
|
||||
|
||||
# CTP Topic 44 AWS Backup in Micro Focus
|
||||
|
||||
**Source:** NAS `/volume2/work/Public Cloud Learning Sessions/CTP _ Topic 44_ AWS Backup in Micro Focus.mp4`
|
||||
|
||||
**Type:** VIDEO | **Category:** 01_AWS-Landing-Zone
|
||||
|
||||
**Status:** ✅ 已完成（Gemini 摘要）
|
||||
|
||||
---
|
||||
|
||||
## 摘要
|
||||
|
||||
AWS Backup 是一个托管服务，用于在 AWS 云中集中化和自动化数据保护。它支持跨账户和跨区域备份，并提供不可变性以防止勒索软件等威胁。该服务为 S3 和 RDS 等服务提供时间点恢复，潜在恢复时间可在 1 秒以内。它还支持法律保留，允许隔离特定备份并保留以满足合规性要求。
|
||||
|
||||
### 灾难恢复策略
|
||||
|
||||
灾难恢复策略根据恢复时间目标（RTO）和恢复点目标（RPO）而有所不同。四种主要策略是：
|
||||
|
||||
- **备份和恢复**：适用于恢复时间为数小时的低优先级情况。
|
||||
- **Pilot Light**：数据复制到 DR 区域，允许在 1 小时内恢复。
|
||||
- **Warm Standby**：应用程序在生产和 DR 区域以较小规模运行，可在几分钟内恢复。
|
||||
- **Active-Active**：提供近乎零停机和数据丢失，但成本最高，应用程序在两个区域同时运行。
|
||||
|
||||
### 当前 AWS 备份流程
|
||||
|
||||
目前，应用程序所有者管理 EC2、EBS、EFS、S3 和数据库等资源的快照。这些快照在 CCIE 门户中注册，并根据标签复制到 DR 区域。对于客户管理的密钥，会执行转换过程。CCIE 门户更新标签以跟踪备份过程并提供错误通知。
|
||||
|
||||
### 当前流程的差距
|
||||
|
||||
当前备份流程是分散的，涉及多个团队，增加了错误风险。快照存储在与资源相同的账户中，一旦账户被攻破会带来风险。CCIE vault 将快照复制到不同区域，但由于成本原因，保留期仅限于三天。备份不是不可变的，CCIE vault 需要新插件来支持新的 AWS 服务。产品组之间的保留期不一致。
|
||||
|
||||
### AWS Backup 详情
|
||||
|
||||
AWS Backup 加密所有备份，包括静态和传输中的数据。一个限制是它无法排除附加到 EC2 实例的特定卷，强制备份所有附加卷。Amazon 不再建议数据库使用热备份，指出快照是崩溃一致的，支持增量备份。
|
||||
|
||||
### 演示亮点
|
||||
|
||||
演示展示了创建备份保管库（用于加密 AWS 备份）、创建备份计划（每日、每小时或自定义计划）、启用 S3 和 RDS 的时间点恢复、按需备份以及从备份保管库恢复（创建新的 EBS 卷或 RDS 实例）。该服务支持基于角色的访问控制，可以使用 CloudWatch 进行监控。
|
||||
|
||||
---
|
||||
|
||||
## 关键概念
|
||||
|
||||
- **AWS Backup**: AWS 托管的集中化数据保护服务
|
||||
- **不可变性 (Immutability)**: 防止备份被篡改或删除
|
||||
- **RTO (Recovery Time Objective)**: 恢复时间目标
|
||||
- **RPO (Recovery Point Objective)**: 恢复点目标
|
||||
- **备份和恢复**: 最基本的 DR 策略，适合低优先级场景
|
||||
- **法律保留 (Legal Holds)**: 用于合规性保留特定备份
|
||||
- **CCIE 门户**: 当前管理快照的内部平台
|
||||
|
||||
---
|
||||
|
||||
## 行动项
|
||||
|
||||
- [ ] 评估现有备份流程是否需要迁移到 AWS Backup
|
||||
- [ ] 审查当前备份的 RTO/RPO 是否满足业务需求
|
||||
- [ ] 考虑跨账户和跨区域备份以提高韧性
|
||||
- [ ] 检查数据库备份是否还在使用热备份模式（不推荐）
|
||||
|
||||
---
|
||||
|
||||
## 相关视频
|
||||
|
||||
> [!info]+ 交叉引用
|
||||
> [[ctp-topic-72-implementing-an-enterprise-dr-strategy-using-aws-backup]] — 企业级 DR 策略实施
|
||||
> [[ctp-topic-73-aws-backup-implementation-of-the-cloud-transformation-program]] — CTP AWS Backup 实施
|
||||
|
||||
---
|
||||
|
||||
*最后更新: 2026-04-15*
|
||||
---
|
||||
title: "CTP Topic 44 AWS Backup in Micro Focus"
|
||||
type: cloud-learning
|
||||
source-type: video
|
||||
category: "DevOps & SRE/01_AWS-Landing-Zone"
|
||||
tags:
|
||||
- AWS
|
||||
- Backup
|
||||
- DR
|
||||
- CTP
|
||||
date-added: 2026-04-14
|
||||
video-source: "nas:///volume2/work/Public Cloud Learning Sessions/CTP _ Topic 44_ AWS Backup in Micro Focus.mp4"
|
||||
audio-source: ""
|
||||
status: summarized (Gemini 摘要)
|
||||
---
|
||||
|
||||
# CTP Topic 44 AWS Backup in Micro Focus
|
||||
|
||||
**Source:** NAS `/volume2/work/Public Cloud Learning Sessions/CTP _ Topic 44_ AWS Backup in Micro Focus.mp4`
|
||||
|
||||
**Type:** VIDEO | **Category:** 01_AWS-Landing-Zone
|
||||
|
||||
**Status:** ✅ 已完成（Gemini 摘要）
|
||||
|
||||
---
|
||||
|
||||
## 摘要
|
||||
|
||||
AWS Backup 是一个托管服务，用于在 AWS 云中集中化和自动化数据保护。它支持跨账户和跨区域备份，并提供不可变性以防止勒索软件等威胁。该服务为 S3 和 RDS 等服务提供时间点恢复，潜在恢复时间可在 1 秒以内。它还支持法律保留，允许隔离特定备份并保留以满足合规性要求。
|
||||
|
||||
### 灾难恢复策略
|
||||
|
||||
灾难恢复策略根据恢复时间目标（RTO）和恢复点目标（RPO）而有所不同。四种主要策略是：
|
||||
|
||||
- **备份和恢复**：适用于恢复时间为数小时的低优先级情况。
|
||||
- **Pilot Light**：数据复制到 DR 区域，允许在 1 小时内恢复。
|
||||
- **Warm Standby**：应用程序在生产和 DR 区域以较小规模运行，可在几分钟内恢复。
|
||||
- **Active-Active**：提供近乎零停机和数据丢失，但成本最高，应用程序在两个区域同时运行。
|
||||
|
||||
### 当前 AWS 备份流程
|
||||
|
||||
目前，应用程序所有者管理 EC2、EBS、EFS、S3 和数据库等资源的快照。这些快照在 CCIE 门户中注册，并根据标签复制到 DR 区域。对于客户管理的密钥，会执行转换过程。CCIE 门户更新标签以跟踪备份过程并提供错误通知。
|
||||
|
||||
### 当前流程的差距
|
||||
|
||||
当前备份流程是分散的，涉及多个团队，增加了错误风险。快照存储在与资源相同的账户中，一旦账户被攻破会带来风险。CCIE vault 将快照复制到不同区域，但由于成本原因，保留期仅限于三天。备份不是不可变的，CCIE vault 需要新插件来支持新的 AWS 服务。产品组之间的保留期不一致。
|
||||
|
||||
### AWS Backup 详情
|
||||
|
||||
AWS Backup 加密所有备份，包括静态和传输中的数据。一个限制是它无法排除附加到 EC2 实例的特定卷，强制备份所有附加卷。Amazon 不再建议数据库使用热备份，指出快照是崩溃一致的，支持增量备份。
|
||||
|
||||
### 演示亮点
|
||||
|
||||
演示展示了创建备份保管库（用于加密 AWS 备份）、创建备份计划（每日、每小时或自定义计划）、启用 S3 和 RDS 的时间点恢复、按需备份以及从备份保管库恢复（创建新的 EBS 卷或 RDS 实例）。该服务支持基于角色的访问控制，可以使用 CloudWatch 进行监控。
|
||||
|
||||
---
|
||||
|
||||
## 关键概念
|
||||
|
||||
- **AWS Backup**: AWS 托管的集中化数据保护服务
|
||||
- **不可变性 (Immutability)**: 防止备份被篡改或删除
|
||||
- **RTO (Recovery Time Objective)**: 恢复时间目标
|
||||
- **RPO (Recovery Point Objective)**: 恢复点目标
|
||||
- **备份和恢复**: 最基本的 DR 策略，适合低优先级场景
|
||||
- **法律保留 (Legal Holds)**: 用于合规性保留特定备份
|
||||
- **CCIE 门户**: 当前管理快照的内部平台
|
||||
|
||||
---
|
||||
|
||||
## 行动项
|
||||
|
||||
- [ ] 评估现有备份流程是否需要迁移到 AWS Backup
|
||||
- [ ] 审查当前备份的 RTO/RPO 是否满足业务需求
|
||||
- [ ] 考虑跨账户和跨区域备份以提高韧性
|
||||
- [ ] 检查数据库备份是否还在使用热备份模式（不推荐）
|
||||
|
||||
---
|
||||
|
||||
## 相关视频
|
||||
|
||||
> [!info]+ 交叉引用
|
||||
> [[ctp-topic-72-implementing-an-enterprise-dr-strategy-using-aws-backup]] — 企业级 DR 策略实施
|
||||
> [[ctp-topic-73-aws-backup-implementation-of-the-cloud-transformation-program]] — CTP AWS Backup 实施
|
||||
|
||||
---
|
||||
|
||||
*最后更新: 2026-04-15*
|
||||
|
||||
@@ -1,97 +1,97 @@
|
||||
---
|
||||
title: CTP Topic 46 NetApps on AWS
|
||||
type: cloud-learning
|
||||
source-type: video
|
||||
category: DevOps & SRE/01_AWS-Landing-Zone
|
||||
tags:
|
||||
- NetApp
|
||||
- AWS
|
||||
- Storage
|
||||
- CTP
|
||||
date-added: 2026-04-14
|
||||
video-source: nas:///volume2/work/Public Cloud Learning Sessions/CTP _ Topic 46_ NetApps on AWS.mp4
|
||||
audio-source: ""
|
||||
status: summarized (Gemini 摘要)
|
||||
---
|
||||
|
||||
# CTP Topic 46 NetApps on AWS
|
||||
|
||||
**Source:** NAS `/volume2/work/Public Cloud Learning Sessions/CTP _ Topic 46_ NetApps on AWS.mp4`
|
||||
|
||||
**Type:** VIDEO | **Category:** 01_AWS-Landing-Zone
|
||||
|
||||
**Status:** 🟡 Awaiting Whisper transcription → Summary
|
||||
|
||||
---
|
||||
|
||||
## 摘要
|
||||
|
||||
> ## NetApp on AWS: A Cloud Transformation Program Learning Session
|
||||
|
||||
Sandeep and Yael presented a training session on NetApp, covering basic components, architecture, data tiering, security, backup/DR strategy, migration from on-prem to cloud, current NetApp usage, architecture, and a demonstration.
|
||||
|
||||
### Traditional NetApp
|
||||
|
||||
NetApp is a storage system, with ONTAP as its operating system. It features controller nodes connected to disk enclosures, supporting SSD, SATA, SAS, and FC disks. NetApp primarily supports SMB, NFS, FC, FCOE, and ISCSI protocols, often configured as a single node or HA pair (high availability pair).
|
||||
|
||||
Key components include:
|
||||
* **Aggregate:** A collection of disks forming a RAID group.
|
||||
* **Volume (FlexVolume):** A data container hosted on top of an aggregate, presented to hosts for data storage, accessible via NFS or CIFS.
|
||||
* **Qtree:** A further segmentation of a volume, similar to directories in UNIX or folders in Windows, with special attributes like permissions and quota management.
|
||||
* **LUN (Logical Unit Number):** A logical representation of storage, hosted on a volume or Qtree, presented to hosts via FC or ISKSI as block-level storage.
|
||||
* **Logical Interface (Lift):** An interface on top of a physical network card, hosting an IP address or WWPN, used for node management, inter-cluster replication, cluster management, and data serving.
|
||||
* **Storage Virtual Machine (SVM):** A virtual segmentation of a NetApp system, enabling multi-tenancy, treating each SVM as a separate operating system with no data flow between them. *At least one SVM is needed for a cluster.*
|
||||
|
||||
### NetApp in AWS (Cloud Volume ONTAP - CVO)
|
||||
|
||||
CVO is a software-only storage appliance hosted on EC2 instances, functioning as nodes. It can be a single node or HA pair, utilizing a mediator instance to aid during takeover and give back processes. The nodes are deployed across multiple availability zones with synchronous replication. EBS disks (GP3, GP2, IEO, IEO1, ST1) are used as storage, managed via Cloud Manager.
|
||||
|
||||
High availability is maintained through a floating IP concept, where clients access data via a unique IP address that migrates to the serving node in case of failure. Takeover give back refers to the process of a serving node taking over services from a failed node and relinquishing them when the failed node recovers.
|
||||
|
||||
### Data Tiering
|
||||
|
||||
Data tiering involves using various storage media to optimize cost, performance, and availability. NetApp in AWS stores active data on EBS and inactive data on S3. Data inactive for 30 days or more is automatically moved to S3 and pulled back to EBS when accessed. *NetApp stores the active data in EBS and inactive data to S3.*
|
||||
|
||||
### Data Security
|
||||
|
||||
NetApp supports encryption via AWS Key Management Service and NetApp Encryption Solution (volume or aggregate encryption), both offering 256-bit encryption. Virus scanning is integrated with McAfee Antivirus (VSES), using an external scan server. Scanning options include on-access (for SMB/CIFS) and on-demand (for NFS) scanning.
|
||||
|
||||
### Backup and DR
|
||||
|
||||
Snapshots are point-in-time, read-only file system images that create copies of volumes using pointers, minimizing space consumption. SnapMirror is a tool for replicating data between NetApps, copying volumes and their snapshots. It requires peering relationships between clusters and SVMs, with optional encryption. Baseline copies perform initial full data replication, while subsequent updates copy only the changes. Destination volumes in a SnapMirror relationship are read-only.
|
||||
|
||||
### Migration
|
||||
|
||||
Tools for migrating from on-prem to AWS include:
|
||||
* **SnapMirror:** Fast, block-level replication, preserving D-Dupe and compression.
|
||||
* **NetApp XCP:** File-based tool, copying data at the file level with concurrent sessions.
|
||||
* **NetApp Cloud Sync:** Used for AWS migrations, supporting NetApp to NetApp, NFS, SMB, NetApp to S3/EFS, and EFS/S3 to NetApp.
|
||||
* **AWS DataSync:** AWS-provided file-based tool for NetApp to EFS or S3 migrations.
|
||||
* **Silver Peak:** A WAN optimizer for compressing packets.
|
||||
|
||||
### Current NetApp Usage and Future Plans
|
||||
|
||||
The organization has around 15 NetApp clusters in various AWS regions, hosting approximately 1.3 petabytes of data. Cloud Manager is used for central management, with storage operations maintaining and supporting the NetApps. Monitoring is currently done through Cityscope and WebTool, with plans to use AWS native services. S3 tiering is enabled for most NetApps, and FSX for NetApp is under POC. There are also plans to use Terraform for deploying NetApps.
|
||||
|
||||
|
||||
---
|
||||
|
||||
## 关键概念
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 行动项
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 相关视频
|
||||
|
||||
> 配对视频笔记链接（生成后填入）
|
||||
|
||||
---
|
||||
|
||||
*最后更新: 2026-04-14*
|
||||
---
|
||||
title: CTP Topic 46 NetApps on AWS
|
||||
type: cloud-learning
|
||||
source-type: video
|
||||
category: DevOps & SRE/01_AWS-Landing-Zone
|
||||
tags:
|
||||
- NetApp
|
||||
- AWS
|
||||
- Storage
|
||||
- CTP
|
||||
date-added: 2026-04-14
|
||||
video-source: nas:///volume2/work/Public Cloud Learning Sessions/CTP _ Topic 46_ NetApps on AWS.mp4
|
||||
audio-source: ""
|
||||
status: summarized (Gemini 摘要)
|
||||
---
|
||||
|
||||
# CTP Topic 46 NetApps on AWS
|
||||
|
||||
**Source:** NAS `/volume2/work/Public Cloud Learning Sessions/CTP _ Topic 46_ NetApps on AWS.mp4`
|
||||
|
||||
**Type:** VIDEO | **Category:** 01_AWS-Landing-Zone
|
||||
|
||||
**Status:** 🟡 Awaiting Whisper transcription → Summary
|
||||
|
||||
---
|
||||
|
||||
## 摘要
|
||||
|
||||
> ## NetApp on AWS: A Cloud Transformation Program Learning Session
|
||||
|
||||
Sandeep and Yael presented a training session on NetApp, covering basic components, architecture, data tiering, security, backup/DR strategy, migration from on-prem to cloud, current NetApp usage, architecture, and a demonstration.
|
||||
|
||||
### Traditional NetApp
|
||||
|
||||
NetApp is a storage system, with ONTAP as its operating system. It features controller nodes connected to disk enclosures, supporting SSD, SATA, SAS, and FC disks. NetApp primarily supports SMB, NFS, FC, FCOE, and ISCSI protocols, often configured as a single node or HA pair (high availability pair).
|
||||
|
||||
Key components include:
|
||||
* **Aggregate:** A collection of disks forming a RAID group.
|
||||
* **Volume (FlexVolume):** A data container hosted on top of an aggregate, presented to hosts for data storage, accessible via NFS or CIFS.
|
||||
* **Qtree:** A further segmentation of a volume, similar to directories in UNIX or folders in Windows, with special attributes like permissions and quota management.
|
||||
* **LUN (Logical Unit Number):** A logical representation of storage, hosted on a volume or Qtree, presented to hosts via FC or ISKSI as block-level storage.
|
||||
* **Logical Interface (Lift):** An interface on top of a physical network card, hosting an IP address or WWPN, used for node management, inter-cluster replication, cluster management, and data serving.
|
||||
* **Storage Virtual Machine (SVM):** A virtual segmentation of a NetApp system, enabling multi-tenancy, treating each SVM as a separate operating system with no data flow between them. *At least one SVM is needed for a cluster.*
|
||||
|
||||
### NetApp in AWS (Cloud Volume ONTAP - CVO)
|
||||
|
||||
CVO is a software-only storage appliance hosted on EC2 instances, functioning as nodes. It can be a single node or HA pair, utilizing a mediator instance to aid during takeover and give back processes. The nodes are deployed across multiple availability zones with synchronous replication. EBS disks (GP3, GP2, IEO, IEO1, ST1) are used as storage, managed via Cloud Manager.
|
||||
|
||||
High availability is maintained through a floating IP concept, where clients access data via a unique IP address that migrates to the serving node in case of failure. Takeover give back refers to the process of a serving node taking over services from a failed node and relinquishing them when the failed node recovers.
|
||||
|
||||
### Data Tiering
|
||||
|
||||
Data tiering involves using various storage media to optimize cost, performance, and availability. NetApp in AWS stores active data on EBS and inactive data on S3. Data inactive for 30 days or more is automatically moved to S3 and pulled back to EBS when accessed. *NetApp stores the active data in EBS and inactive data to S3.*
|
||||
|
||||
### Data Security
|
||||
|
||||
NetApp supports encryption via AWS Key Management Service and NetApp Encryption Solution (volume or aggregate encryption), both offering 256-bit encryption. Virus scanning is integrated with McAfee Antivirus (VSES), using an external scan server. Scanning options include on-access (for SMB/CIFS) and on-demand (for NFS) scanning.
|
||||
|
||||
### Backup and DR
|
||||
|
||||
Snapshots are point-in-time, read-only file system images that create copies of volumes using pointers, minimizing space consumption. SnapMirror is a tool for replicating data between NetApps, copying volumes and their snapshots. It requires peering relationships between clusters and SVMs, with optional encryption. Baseline copies perform initial full data replication, while subsequent updates copy only the changes. Destination volumes in a SnapMirror relationship are read-only.
|
||||
|
||||
### Migration
|
||||
|
||||
Tools for migrating from on-prem to AWS include:
|
||||
* **SnapMirror:** Fast, block-level replication, preserving D-Dupe and compression.
|
||||
* **NetApp XCP:** File-based tool, copying data at the file level with concurrent sessions.
|
||||
* **NetApp Cloud Sync:** Used for AWS migrations, supporting NetApp to NetApp, NFS, SMB, NetApp to S3/EFS, and EFS/S3 to NetApp.
|
||||
* **AWS DataSync:** AWS-provided file-based tool for NetApp to EFS or S3 migrations.
|
||||
* **Silver Peak:** A WAN optimizer for compressing packets.
|
||||
|
||||
### Current NetApp Usage and Future Plans
|
||||
|
||||
The organization has around 15 NetApp clusters in various AWS regions, hosting approximately 1.3 petabytes of data. Cloud Manager is used for central management, with storage operations maintaining and supporting the NetApps. Monitoring is currently done through Cityscope and WebTool, with plans to use AWS native services. S3 tiering is enabled for most NetApps, and FSX for NetApp is under POC. There are also plans to use Terraform for deploying NetApps.
|
||||
|
||||
|
||||
---
|
||||
|
||||
## 关键概念
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 行动项
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 相关视频
|
||||
|
||||
> 配对视频笔记链接（生成后填入）
|
||||
|
||||
---
|
||||
|
||||
*最后更新: 2026-04-14*
|
||||
|
||||
@@ -1,51 +1,51 @@
|
||||
---
|
||||
title: CTP Topic 46 NetApps on AWS
|
||||
type: cloud-learning
|
||||
source-type: video
|
||||
category: DevOps & SRE/01_AWS-Landing-Zone
|
||||
tags:
|
||||
- NetApp
|
||||
- AWS
|
||||
- Storage
|
||||
- CTP
|
||||
date-added: 2026-04-14
|
||||
video-source: nas:///volume2/work/Public Cloud Learning Sessions/CTP _ Topic 46_ NetApps on AWS.mp4
|
||||
audio-source: ""
|
||||
status: raw
|
||||
---
|
||||
|
||||
# CTP Topic 46 NetApps on AWS
|
||||
|
||||
**Source:** NAS `/volume2/work/Public Cloud Learning Sessions/CTP _ Topic 46_ NetApps on AWS.mp4`
|
||||
|
||||
**Type:** VIDEO | **Category:** 01_AWS-Landing-Zone
|
||||
|
||||
**Status:** 🟡 Awaiting Whisper transcription → Summary
|
||||
|
||||
---
|
||||
|
||||
## 摘要
|
||||
|
||||
> 待转录后由 LLM 生成
|
||||
|
||||
---
|
||||
|
||||
## 关键概念
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 行动项
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 相关视频
|
||||
|
||||
> 配对视频笔记链接（生成后填入）
|
||||
|
||||
---
|
||||
|
||||
*最后更新: 2026-04-14*
|
||||
---
|
||||
title: CTP Topic 46 NetApps on AWS
|
||||
type: cloud-learning
|
||||
source-type: video
|
||||
category: DevOps & SRE/01_AWS-Landing-Zone
|
||||
tags:
|
||||
- NetApp
|
||||
- AWS
|
||||
- Storage
|
||||
- CTP
|
||||
date-added: 2026-04-14
|
||||
video-source: nas:///volume2/work/Public Cloud Learning Sessions/CTP _ Topic 46_ NetApps on AWS.mp4
|
||||
audio-source: ""
|
||||
status: raw
|
||||
---
|
||||
|
||||
# CTP Topic 46 NetApps on AWS
|
||||
|
||||
**Source:** NAS `/volume2/work/Public Cloud Learning Sessions/CTP _ Topic 46_ NetApps on AWS.mp4`
|
||||
|
||||
**Type:** VIDEO | **Category:** 01_AWS-Landing-Zone
|
||||
|
||||
**Status:** 🟡 Awaiting Whisper transcription → Summary
|
||||
|
||||
---
|
||||
|
||||
## 摘要
|
||||
|
||||
> 待转录后由 LLM 生成
|
||||
|
||||
---
|
||||
|
||||
## 关键概念
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 行动项
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 相关视频
|
||||
|
||||
> 配对视频笔记链接（生成后填入）
|
||||
|
||||
---
|
||||
|
||||
*最后更新: 2026-04-14*
|
||||
|
||||
@@ -1,64 +1,64 @@
|
||||
---
|
||||
title: CTP Topic 47 Enterprise Architecture Cloud Standards
|
||||
type: cloud-learning
|
||||
source-type: video
|
||||
category: DevOps & SRE/01_AWS-Landing-Zone
|
||||
tags:
|
||||
- Enterprise-Architecture
|
||||
- Cloud-Standards
|
||||
- CTP
|
||||
date-added: 2026-04-14
|
||||
video-source: nas:///volume2/work/Public Cloud Learning Sessions/CTP _ Topic 47_Enterprise Architecture Cloud Standards.mp4
|
||||
audio-source: ""
|
||||
status: summarized (Gemini 摘要)
|
||||
---
|
||||
|
||||
# CTP Topic 47 Enterprise Architecture Cloud Standards
|
||||
|
||||
**Source:** NAS `/volume2/work/Public Cloud Learning Sessions/CTP _ Topic 47_Enterprise Architecture Cloud Standards.mp4`
|
||||
|
||||
**Type:** VIDEO | **Category:** 01_AWS-Landing-Zone
|
||||
|
||||
**Status:** 🟡 Awaiting Whisper transcription → Summary
|
||||
|
||||
---
|
||||
|
||||
## 摘要
|
||||
|
||||
> ## Enterprise Architecture Cloud Standards
|
||||
|
||||
[slide:N]
|
||||
The session will cover landing zones, their purpose, the role of enterprise architecture in cloud environments, guardrails, and the need for community input. The speaker, Lindsay, an enterprise architect with a development background, aims to provide a learner's perspective on cloud architecture.
|
||||
|
||||
A landing zone is a framework for hosting cloud workloads, focusing on security, compliance, and manageability. Key components include account structure, networking, security, access management, and telemetry. *The account structure aligns with environments (dev, staging, production), and roles define access based on zero trust and least privilege principles.* The landing zone provides pre-configured networking and security, reducing the security review burden on application teams. Centralized logging and auditing are provided within the framework.
|
||||
|
||||
Benefits of using landing zones include a pre-designed security model, pre-built compliance, and visible cost control. Infrastructure automation, using Terraform, enables efficient environment configuration. *Terraform allows specifying the desired environment in code, promoting standardization and testability.* Terragrunt, a wrapper for Terraform, aids in generating different environments. The framework eliminates reinvention, allowing application teams to focus on application-specific tasks.
|
||||
|
||||
Enterprise architecture helps articulate the cloud architecture, informing application teams about available resources and requirements. Guardrails capture mandatory requirements and optimal practices for scalability, cost minimization, and flexibility. The enterprise architecture team has created a page on the intranet site with business architecture concepts, data connections, application information, and technology roadmaps.
|
||||
|
||||
The cloud guardrails document covers design concepts, capabilities, and best practices. Key design concepts include cloud-first, leveraging well-architected frameworks, infrastructure as code (Terraform), and resource tagging. The document provides guidance on executable packaging, functional partitioning, capacity management, and identity management.
|
||||
|
||||
Executable packaging prioritizes using existing cloud services and managed services to minimize custom code. Functional partitioning involves breaking monolithic applications into smaller, independent blocks or serverless functions. The speaker emphasizes the need for input from application teams to refine the guardrails and incorporate real-world experiences. *We want your knowledge collected here for reuse and help help to help other app developers down the road.*
|
||||
|
||||
|
||||
---
|
||||
|
||||
## 关键概念
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 行动项
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 相关视频
|
||||
|
||||
> 配对视频笔记链接（生成后填入）
|
||||
|
||||
---
|
||||
|
||||
*最后更新: 2026-04-14*
|
||||
---
|
||||
title: CTP Topic 47 Enterprise Architecture Cloud Standards
|
||||
type: cloud-learning
|
||||
source-type: video
|
||||
category: DevOps & SRE/01_AWS-Landing-Zone
|
||||
tags:
|
||||
- Enterprise-Architecture
|
||||
- Cloud-Standards
|
||||
- CTP
|
||||
date-added: 2026-04-14
|
||||
video-source: nas:///volume2/work/Public Cloud Learning Sessions/CTP _ Topic 47_Enterprise Architecture Cloud Standards.mp4
|
||||
audio-source: ""
|
||||
status: summarized (Gemini 摘要)
|
||||
---
|
||||
|
||||
# CTP Topic 47 Enterprise Architecture Cloud Standards
|
||||
|
||||
**Source:** NAS `/volume2/work/Public Cloud Learning Sessions/CTP _ Topic 47_Enterprise Architecture Cloud Standards.mp4`
|
||||
|
||||
**Type:** VIDEO | **Category:** 01_AWS-Landing-Zone
|
||||
|
||||
**Status:** 🟡 Awaiting Whisper transcription → Summary
|
||||
|
||||
---
|
||||
|
||||
## 摘要
|
||||
|
||||
> ## Enterprise Architecture Cloud Standards
|
||||
|
||||
[slide:N]
|
||||
The session will cover landing zones, their purpose, the role of enterprise architecture in cloud environments, guardrails, and the need for community input. The speaker, Lindsay, an enterprise architect with a development background, aims to provide a learner's perspective on cloud architecture.
|
||||
|
||||
A landing zone is a framework for hosting cloud workloads, focusing on security, compliance, and manageability. Key components include account structure, networking, security, access management, and telemetry. *The account structure aligns with environments (dev, staging, production), and roles define access based on zero trust and least privilege principles.* The landing zone provides pre-configured networking and security, reducing the security review burden on application teams. Centralized logging and auditing are provided within the framework.
|
||||
|
||||
Benefits of using landing zones include a pre-designed security model, pre-built compliance, and visible cost control. Infrastructure automation, using Terraform, enables efficient environment configuration. *Terraform allows specifying the desired environment in code, promoting standardization and testability.* Terragrunt, a wrapper for Terraform, aids in generating different environments. The framework eliminates reinvention, allowing application teams to focus on application-specific tasks.
|
||||
|
||||
Enterprise architecture helps articulate the cloud architecture, informing application teams about available resources and requirements. Guardrails capture mandatory requirements and optimal practices for scalability, cost minimization, and flexibility. The enterprise architecture team has created a page on the intranet site with business architecture concepts, data connections, application information, and technology roadmaps.
|
||||
|
||||
The cloud guardrails document covers design concepts, capabilities, and best practices. Key design concepts include cloud-first, leveraging well-architected frameworks, infrastructure as code (Terraform), and resource tagging. The document provides guidance on executable packaging, functional partitioning, capacity management, and identity management.
|
||||
|
||||
Executable packaging prioritizes using existing cloud services and managed services to minimize custom code. Functional partitioning involves breaking monolithic applications into smaller, independent blocks or serverless functions. The speaker emphasizes the need for input from application teams to refine the guardrails and incorporate real-world experiences. *We want your knowledge collected here for reuse and help help to help other app developers down the road.*
|
||||
|
||||
|
||||
---
|
||||
|
||||
## 关键概念
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 行动项
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 相关视频
|
||||
|
||||
> 配对视频笔记链接（生成后填入）
|
||||
|
||||
---
|
||||
|
||||
*最后更新: 2026-04-14*
|
||||
|
||||
@@ -1,50 +1,50 @@
|
||||
---
|
||||
title: CTP Topic 47 Enterprise Architecture Cloud Standards
|
||||
type: cloud-learning
|
||||
source-type: video
|
||||
category: DevOps & SRE/01_AWS-Landing-Zone
|
||||
tags:
|
||||
- Enterprise-Architecture
|
||||
- Cloud-Standards
|
||||
- CTP
|
||||
date-added: 2026-04-14
|
||||
video-source: nas:///volume2/work/Public Cloud Learning Sessions/CTP _ Topic 47_Enterprise Architecture Cloud Standards.mp4
|
||||
audio-source: ""
|
||||
status: raw
|
||||
---
|
||||
|
||||
# CTP Topic 47 Enterprise Architecture Cloud Standards
|
||||
|
||||
**Source:** NAS `/volume2/work/Public Cloud Learning Sessions/CTP _ Topic 47_Enterprise Architecture Cloud Standards.mp4`
|
||||
|
||||
**Type:** VIDEO | **Category:** 01_AWS-Landing-Zone
|
||||
|
||||
**Status:** 🟡 Awaiting Whisper transcription → Summary
|
||||
|
||||
---
|
||||
|
||||
## 摘要
|
||||
|
||||
> 待转录后由 LLM 生成
|
||||
|
||||
---
|
||||
|
||||
## 关键概念
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 行动项
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 相关视频
|
||||
|
||||
> 配对视频笔记链接（生成后填入）
|
||||
|
||||
---
|
||||
|
||||
*最后更新: 2026-04-14*
|
||||
---
|
||||
title: CTP Topic 47 Enterprise Architecture Cloud Standards
|
||||
type: cloud-learning
|
||||
source-type: video
|
||||
category: DevOps & SRE/01_AWS-Landing-Zone
|
||||
tags:
|
||||
- Enterprise-Architecture
|
||||
- Cloud-Standards
|
||||
- CTP
|
||||
date-added: 2026-04-14
|
||||
video-source: nas:///volume2/work/Public Cloud Learning Sessions/CTP _ Topic 47_Enterprise Architecture Cloud Standards.mp4
|
||||
audio-source: ""
|
||||
status: raw
|
||||
---
|
||||
|
||||
# CTP Topic 47 Enterprise Architecture Cloud Standards
|
||||
|
||||
**Source:** NAS `/volume2/work/Public Cloud Learning Sessions/CTP _ Topic 47_Enterprise Architecture Cloud Standards.mp4`
|
||||
|
||||
**Type:** VIDEO | **Category:** 01_AWS-Landing-Zone
|
||||
|
||||
**Status:** 🟡 Awaiting Whisper transcription → Summary
|
||||
|
||||
---
|
||||
|
||||
## 摘要
|
||||
|
||||
> 待转录后由 LLM 生成
|
||||
|
||||
---
|
||||
|
||||
## 关键概念
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 行动项
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 相关视频
|
||||
|
||||
> 配对视频笔记链接（生成后填入）
|
||||
|
||||
---
|
||||
|
||||
*最后更新: 2026-04-14*
|
||||
|
||||
@@ -1,62 +1,62 @@
|
||||
---
|
||||
title: CTP Topic 50 AMI Roadmap for AWS AMIs
|
||||
type: cloud-learning
|
||||
source-type: video
|
||||
category: DevOps & SRE/01_AWS-Landing-Zone
|
||||
tags:
|
||||
- AWS
|
||||
- AMI
|
||||
- Roadmap
|
||||
- CTP
|
||||
date-added: 2026-04-14
|
||||
video-source: nas:///volume2/work/Public Cloud Learning Sessions/CTP _ Topic 50_ AMI Roadmap for AWS AMIs.mp4
|
||||
audio-source: ""
|
||||
status: summarized (Gemini 摘要)
|
||||
---
|
||||
|
||||
# CTP Topic 50 AMI Roadmap for AWS AMIs
|
||||
|
||||
**Source:** NAS `/volume2/work/Public Cloud Learning Sessions/CTP _ Topic 50_ AMI Roadmap for AWS AMIs.mp4`
|
||||
|
||||
**Type:** VIDEO | **Category:** 01_AWS-Landing-Zone
|
||||
|
||||
**Status:** 🟡 Awaiting Whisper transcription → Summary
|
||||
|
||||
---
|
||||
|
||||
## 摘要
|
||||
|
||||
> ## AMI Roadmap for AWS AMIs
|
||||
|
||||
The Cloud Transformation Program held a learning session to discuss the AMI roadmap for AWS AMIs. The session covered the CCOE AMI roadmap, end-of-life operating systems, AMI notifications, change logs, new features, the process for adding new AMIs, current supported AMIs, and the roadmap.
|
||||
|
||||
The CCOE provides hardened AMIs on a bi-monthly basis aligned with security standards. The session focused on the roadmap, not the hardened AMIs themselves. The current available AMIs include three versions of Ubuntu, CentOS 7 and 8, Reddit 8.4 ARM, Amazon Linux 2, and four versions of Windows operating systems.
|
||||
|
||||
The roadmap includes planned releases for new operating systems. In November, SLES 15 and Reddit 9 will be released. In January 2023, open Susa 15 and Amazon Linux 2022 will be added. In March 2023, Rocky 8 and Rocky 9 will be available. May 2023 will see Reddit 9.4 ARM and Ubuntu 22.04 ARM. *Starting May 2023, all ARM processors related to AMIs will be released.* The order was created mainly by ADM requirements. Any requirements to change the prioritization of the roadmap should go through the demand pipeline process.
|
||||
|
||||
Windows Server 2008 and 2008 R2 are end-of-life since January 2020, CentOS 8 since December 2021, and Windows Server 2012 will be by October 2023. Red Hat 7 will be end-of-life by June 2024, as will CentOS 7. AMI notifications are sent via email to those on the CCOE notifications PDL. A change log is now available in the CCRE portal, representing the latest changes from the previous release. *This change log focuses on changes done by CCRE.*
|
||||
|
||||
The features contained in the AMIs include domain join services, enabling SSHR, integrating McAfee antivirus services, enabling DNS settings, updating the cloud init process, enabling the SSM client, and edge installations. The process of adding new AMI integration and validation involves integrating services, enabling features, and undergoing a build and test process. The AMIs are shared with every account in the organization, including the AMI itself, EBS volumes, and KMS keys.
|
||||
|
||||
|
||||
---
|
||||
|
||||
## 关键概念
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 行动项
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 相关视频
|
||||
|
||||
> 配对视频笔记链接（生成后填入）
|
||||
|
||||
---
|
||||
|
||||
*最后更新: 2026-04-14*
|
||||
---
|
||||
title: CTP Topic 50 AMI Roadmap for AWS AMIs
|
||||
type: cloud-learning
|
||||
source-type: video
|
||||
category: DevOps & SRE/01_AWS-Landing-Zone
|
||||
tags:
|
||||
- AWS
|
||||
- AMI
|
||||
- Roadmap
|
||||
- CTP
|
||||
date-added: 2026-04-14
|
||||
video-source: nas:///volume2/work/Public Cloud Learning Sessions/CTP _ Topic 50_ AMI Roadmap for AWS AMIs.mp4
|
||||
audio-source: ""
|
||||
status: summarized (Gemini 摘要)
|
||||
---
|
||||
|
||||
# CTP Topic 50 AMI Roadmap for AWS AMIs
|
||||
|
||||
**Source:** NAS `/volume2/work/Public Cloud Learning Sessions/CTP _ Topic 50_ AMI Roadmap for AWS AMIs.mp4`
|
||||
|
||||
**Type:** VIDEO | **Category:** 01_AWS-Landing-Zone
|
||||
|
||||
**Status:** 🟡 Awaiting Whisper transcription → Summary
|
||||
|
||||
---
|
||||
|
||||
## 摘要
|
||||
|
||||
> ## AMI Roadmap for AWS AMIs
|
||||
|
||||
The Cloud Transformation Program held a learning session to discuss the AMI roadmap for AWS AMIs. The session covered the CCOE AMI roadmap, end-of-life operating systems, AMI notifications, change logs, new features, the process for adding new AMIs, current supported AMIs, and the roadmap.
|
||||
|
||||
The CCOE provides hardened AMIs on a bi-monthly basis aligned with security standards. The session focused on the roadmap, not the hardened AMIs themselves. The current available AMIs include three versions of Ubuntu, CentOS 7 and 8, Reddit 8.4 ARM, Amazon Linux 2, and four versions of Windows operating systems.
|
||||
|
||||
The roadmap includes planned releases for new operating systems. In November, SLES 15 and Reddit 9 will be released. In January 2023, open Susa 15 and Amazon Linux 2022 will be added. In March 2023, Rocky 8 and Rocky 9 will be available. May 2023 will see Reddit 9.4 ARM and Ubuntu 22.04 ARM. *Starting May 2023, all ARM processors related to AMIs will be released.* The order was created mainly by ADM requirements. Any requirements to change the prioritization of the roadmap should go through the demand pipeline process.
|
||||
|
||||
Windows Server 2008 and 2008 R2 are end-of-life since January 2020, CentOS 8 since December 2021, and Windows Server 2012 will be by October 2023. Red Hat 7 will be end-of-life by June 2024, as will CentOS 7. AMI notifications are sent via email to those on the CCOE notifications PDL. A change log is now available in the CCRE portal, representing the latest changes from the previous release. *This change log focuses on changes done by CCRE.*
|
||||
|
||||
The features contained in the AMIs include domain join services, enabling SSHR, integrating McAfee antivirus services, enabling DNS settings, updating the cloud init process, enabling the SSM client, and edge installations. The process of adding new AMI integration and validation involves integrating services, enabling features, and undergoing a build and test process. The AMIs are shared with every account in the organization, including the AMI itself, EBS volumes, and KMS keys.
|
||||
|
||||
|
||||
---
|
||||
|
||||
## 关键概念
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 行动项
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 相关视频
|
||||
|
||||
> 配对视频笔记链接（生成后填入）
|
||||
|
||||
---
|
||||
|
||||
*最后更新: 2026-04-14*
|
||||
|
||||
@@ -1,51 +1,51 @@
|
||||
---
|
||||
title: CTP Topic 50 AMI Roadmap for AWS AMIs
|
||||
type: cloud-learning
|
||||
source-type: video
|
||||
category: DevOps & SRE/01_AWS-Landing-Zone
|
||||
tags:
|
||||
- AWS
|
||||
- AMI
|
||||
- Roadmap
|
||||
- CTP
|
||||
date-added: 2026-04-14
|
||||
video-source: nas:///volume2/work/Public Cloud Learning Sessions/CTP _ Topic 50_ AMI Roadmap for AWS AMIs.mp4
|
||||
audio-source: ""
|
||||
status: raw
|
||||
---
|
||||
|
||||
# CTP Topic 50 AMI Roadmap for AWS AMIs
|
||||
|
||||
**Source:** NAS `/volume2/work/Public Cloud Learning Sessions/CTP _ Topic 50_ AMI Roadmap for AWS AMIs.mp4`
|
||||
|
||||
**Type:** VIDEO | **Category:** 01_AWS-Landing-Zone
|
||||
|
||||
**Status:** 🟡 Awaiting Whisper transcription → Summary
|
||||
|
||||
---
|
||||
|
||||
## 摘要
|
||||
|
||||
> 待转录后由 LLM 生成
|
||||
|
||||
---
|
||||
|
||||
## 关键概念
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 行动项
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 相关视频
|
||||
|
||||
> 配对视频笔记链接（生成后填入）
|
||||
|
||||
---
|
||||
|
||||
*最后更新: 2026-04-14*
|
||||
---
|
||||
title: CTP Topic 50 AMI Roadmap for AWS AMIs
|
||||
type: cloud-learning
|
||||
source-type: video
|
||||
category: DevOps & SRE/01_AWS-Landing-Zone
|
||||
tags:
|
||||
- AWS
|
||||
- AMI
|
||||
- Roadmap
|
||||
- CTP
|
||||
date-added: 2026-04-14
|
||||
video-source: nas:///volume2/work/Public Cloud Learning Sessions/CTP _ Topic 50_ AMI Roadmap for AWS AMIs.mp4
|
||||
audio-source: ""
|
||||
status: raw
|
||||
---
|
||||
|
||||
# CTP Topic 50 AMI Roadmap for AWS AMIs
|
||||
|
||||
**Source:** NAS `/volume2/work/Public Cloud Learning Sessions/CTP _ Topic 50_ AMI Roadmap for AWS AMIs.mp4`
|
||||
|
||||
**Type:** VIDEO | **Category:** 01_AWS-Landing-Zone
|
||||
|
||||
**Status:** 🟡 Awaiting Whisper transcription → Summary
|
||||
|
||||
---
|
||||
|
||||
## 摘要
|
||||
|
||||
> 待转录后由 LLM 生成
|
||||
|
||||
---
|
||||
|
||||
## 关键概念
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 行动项
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 相关视频
|
||||
|
||||
> 配对视频笔记链接（生成后填入）
|
||||
|
||||
---
|
||||
|
||||
*最后更新: 2026-04-14*
|
||||
|
||||
@@ -1,68 +1,68 @@
|
||||
---
|
||||
title: CTP Topic 51 Architecting with AWS purpose-built databases
|
||||
type: cloud-learning
|
||||
source-type: video
|
||||
category: DevOps & SRE/01_AWS-Landing-Zone
|
||||
tags:
|
||||
- AWS
|
||||
- Database
|
||||
- Purpose-Built
|
||||
- CTP
|
||||
date-added: 2026-04-14
|
||||
video-source: nas:///volume2/work/Public Cloud Learning Sessions/CTP _ Topic 51_ Architecting with AWS purpose-built databases.mp4
|
||||
audio-source: ""
|
||||
status: summarized (Gemini 摘要)
|
||||
---
|
||||
|
||||
# CTP Topic 51 Architecting with AWS purpose-built databases
|
||||
|
||||
**Source:** NAS `/volume2/work/Public Cloud Learning Sessions/CTP _ Topic 51_ Architecting with AWS purpose-built databases.mp4`
|
||||
|
||||
**Type:** VIDEO | **Category:** 01_AWS-Landing-Zone
|
||||
|
||||
**Status:** 🟡 Awaiting Whisper transcription → Summary
|
||||
|
||||
---
|
||||
|
||||
## 摘要
|
||||
|
||||
> ## Architecting with AWS Purpose-Built Databases
|
||||
|
||||
Femi George, a database sales specialist from AWS, discussed purpose-built databases for modern applications, covering modern applications, the rationale for purpose-built databases, key AWS databases, and the evolving role of DBAs/developers in the cloud.
|
||||
|
||||
Modern applications have evolved from client-server models due to changing customer requirements, new devices, diverse data types, and economic considerations. Key questions include scalability, global delivery with low latency, and developer access. The approach involves starting with the use case and selecting the best tool for the job, avoiding a one-size-fits-all approach. *We need to start thinking of the right purpose built database for the right application.*
|
||||
|
||||
Considerations for purpose-built databases include application scale, user numbers, access patterns, usage spikes, and performance requirements like latency and availability. Duolingo uses DynamoDB for personalized data, ElastiCache for common words/phrases, and Aurora for transactional data. AWS offers a range of purpose-built databases, including relational (e.g., RDS, Aurora) and NoSQL (key-value, document, in-memory, graph) options, along with time series, ledger, and wide-column databases.
|
||||
|
||||
Relational databases are suitable for fixed schemas and maintaining referential integrity. Amazon RDS provides fully managed traditional and open-source databases, handling backups and patching. Data endpoints in RDS facilitate easy application access. Amazon Aurora, a cloud-native database, offers MySQL and PostgreSQL compatibility with enhanced performance, scalability, and security. *Amazon Aurora has two flavors, MySQL and PostgreSQL.* Aurora separates storage and compute, improving IO and availability.
|
||||
|
||||
Key-value data is popular among developers and forms the basis of NoSQL databases. Amazon DynamoDB is a key-value and document database with single-digit millisecond performance at any scale, supporting trillions of requests per day. Netflix uses DynamoDB for resilience and low-latency access to JSON documents. Document databases extend key-value stores by enabling deeper querying within JSON files. Amazon DocumentDB is compatible with MongoDB and offers flexible schemas.
|
||||
|
||||
Apache Cassandra, a wide-column database, is used for large-scale applications with unstructured schemas. Amazon Keyspaces is a managed service for Cassandra-compatible databases, offering serverless options. In-memory databases, like Amazon ElastiCache (Redis, Memcached), are used for caching, media streaming, session stores, and real-time analytics. Peloton uses ElastiCache Redis for immediate feedback to customers.
|
||||
|
||||
Graph databases (e.g., Amazon Neptune) are suitable for fraud detection, social networking, and recommendations. They help uncover correlations that relational databases struggle with. Time series databases (e.g., Amazon Timestream) are designed for high-volume, time-based data analysis, such as data from IoT devices.
|
||||
|
||||
The role of the DBA is evolving in the cloud. While AWS manages much of the platform, DBAs still handle tasks like restoring databases, managing access, and optimizing queries. The focus shifts from platform management to application innovation.
|
||||
|
||||
|
||||
---
|
||||
|
||||
## 关键概念
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 行动项
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 相关视频
|
||||
|
||||
> 配对视频笔记链接（生成后填入）
|
||||
|
||||
---
|
||||
|
||||
*最后更新: 2026-04-14*
|
||||
---
|
||||
title: CTP Topic 51 Architecting with AWS purpose-built databases
|
||||
type: cloud-learning
|
||||
source-type: video
|
||||
category: DevOps & SRE/01_AWS-Landing-Zone
|
||||
tags:
|
||||
- AWS
|
||||
- Database
|
||||
- Purpose-Built
|
||||
- CTP
|
||||
date-added: 2026-04-14
|
||||
video-source: nas:///volume2/work/Public Cloud Learning Sessions/CTP _ Topic 51_ Architecting with AWS purpose-built databases.mp4
|
||||
audio-source: ""
|
||||
status: summarized (Gemini 摘要)
|
||||
---
|
||||
|
||||
# CTP Topic 51 Architecting with AWS purpose-built databases
|
||||
|
||||
**Source:** NAS `/volume2/work/Public Cloud Learning Sessions/CTP _ Topic 51_ Architecting with AWS purpose-built databases.mp4`
|
||||
|
||||
**Type:** VIDEO | **Category:** 01_AWS-Landing-Zone
|
||||
|
||||
**Status:** 🟡 Awaiting Whisper transcription → Summary
|
||||
|
||||
---
|
||||
|
||||
## 摘要
|
||||
|
||||
> ## Architecting with AWS Purpose-Built Databases
|
||||
|
||||
Femi George, a database sales specialist from AWS, discussed purpose-built databases for modern applications, covering modern applications, the rationale for purpose-built databases, key AWS databases, and the evolving role of DBAs/developers in the cloud.
|
||||
|
||||
Modern applications have evolved from client-server models due to changing customer requirements, new devices, diverse data types, and economic considerations. Key questions include scalability, global delivery with low latency, and developer access. The approach involves starting with the use case and selecting the best tool for the job, avoiding a one-size-fits-all approach. *We need to start thinking of the right purpose built database for the right application.*
|
||||
|
||||
Considerations for purpose-built databases include application scale, user numbers, access patterns, usage spikes, and performance requirements like latency and availability. Duolingo uses DynamoDB for personalized data, ElastiCache for common words/phrases, and Aurora for transactional data. AWS offers a range of purpose-built databases, including relational (e.g., RDS, Aurora) and NoSQL (key-value, document, in-memory, graph) options, along with time series, ledger, and wide-column databases.
|
||||
|
||||
Relational databases are suitable for fixed schemas and maintaining referential integrity. Amazon RDS provides fully managed traditional and open-source databases, handling backups and patching. Data endpoints in RDS facilitate easy application access. Amazon Aurora, a cloud-native database, offers MySQL and PostgreSQL compatibility with enhanced performance, scalability, and security. *Amazon Aurora has two flavors, MySQL and PostgreSQL.* Aurora separates storage and compute, improving IO and availability.
|
||||
|
||||
Key-value data is popular among developers and forms the basis of NoSQL databases. Amazon DynamoDB is a key-value and document database with single-digit millisecond performance at any scale, supporting trillions of requests per day. Netflix uses DynamoDB for resilience and low-latency access to JSON documents. Document databases extend key-value stores by enabling deeper querying within JSON files. Amazon DocumentDB is compatible with MongoDB and offers flexible schemas.
|
||||
|
||||
Apache Cassandra, a wide-column database, is used for large-scale applications with unstructured schemas. Amazon Keyspaces is a managed service for Cassandra-compatible databases, offering serverless options. In-memory databases, like Amazon ElastiCache (Redis, Memcached), are used for caching, media streaming, session stores, and real-time analytics. Peloton uses ElastiCache Redis for immediate feedback to customers.
|
||||
|
||||
Graph databases (e.g., Amazon Neptune) are suitable for fraud detection, social networking, and recommendations. They help uncover correlations that relational databases struggle with. Time series databases (e.g., Amazon Timestream) are designed for high-volume, time-based data analysis, such as data from IoT devices.
|
||||
|
||||
The role of the DBA is evolving in the cloud. While AWS manages much of the platform, DBAs still handle tasks like restoring databases, managing access, and optimizing queries. The focus shifts from platform management to application innovation.
|
||||
|
||||
|
||||
---
|
||||
|
||||
## 关键概念
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 行动项
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 相关视频
|
||||
|
||||
> 配对视频笔记链接（生成后填入）
|
||||
|
||||
---
|
||||
|
||||
*最后更新: 2026-04-14*
|
||||
|
||||
@@ -1,51 +1,51 @@
|
||||
---
|
||||
title: CTP Topic 51 Architecting with AWS purpose-built databases
|
||||
type: cloud-learning
|
||||
source-type: video
|
||||
category: DevOps & SRE/01_AWS-Landing-Zone
|
||||
tags:
|
||||
- AWS
|
||||
- Database
|
||||
- Purpose-Built
|
||||
- CTP
|
||||
date-added: 2026-04-14
|
||||
video-source: nas:///volume2/work/Public Cloud Learning Sessions/CTP _ Topic 51_ Architecting with AWS purpose-built databases.mp4
|
||||
audio-source: ""
|
||||
status: raw
|
||||
---
|
||||
|
||||
# CTP Topic 51 Architecting with AWS purpose-built databases
|
||||
|
||||
**Source:** NAS `/volume2/work/Public Cloud Learning Sessions/CTP _ Topic 51_ Architecting with AWS purpose-built databases.mp4`
|
||||
|
||||
**Type:** VIDEO | **Category:** 01_AWS-Landing-Zone
|
||||
|
||||
**Status:** 🟡 Awaiting Whisper transcription → Summary
|
||||
|
||||
---
|
||||
|
||||
## 摘要
|
||||
|
||||
> 待转录后由 LLM 生成
|
||||
|
||||
---
|
||||
|
||||
## 关键概念
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 行动项
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 相关视频
|
||||
|
||||
> 配对视频笔记链接（生成后填入）
|
||||
|
||||
---
|
||||
|
||||
*最后更新: 2026-04-14*
|
||||
---
|
||||
title: CTP Topic 51 Architecting with AWS purpose-built databases
|
||||
type: cloud-learning
|
||||
source-type: video
|
||||
category: DevOps & SRE/01_AWS-Landing-Zone
|
||||
tags:
|
||||
- AWS
|
||||
- Database
|
||||
- Purpose-Built
|
||||
- CTP
|
||||
date-added: 2026-04-14
|
||||
video-source: nas:///volume2/work/Public Cloud Learning Sessions/CTP _ Topic 51_ Architecting with AWS purpose-built databases.mp4
|
||||
audio-source: ""
|
||||
status: raw
|
||||
---
|
||||
|
||||
# CTP Topic 51 Architecting with AWS purpose-built databases
|
||||
|
||||
**Source:** NAS `/volume2/work/Public Cloud Learning Sessions/CTP _ Topic 51_ Architecting with AWS purpose-built databases.mp4`
|
||||
|
||||
**Type:** VIDEO | **Category:** 01_AWS-Landing-Zone
|
||||
|
||||
**Status:** 🟡 Awaiting Whisper transcription → Summary
|
||||
|
||||
---
|
||||
|
||||
## 摘要
|
||||
|
||||
> 待转录后由 LLM 生成
|
||||
|
||||
---
|
||||
|
||||
## 关键概念
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 行动项
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 相关视频
|
||||
|
||||
> 配对视频笔记链接（生成后填入）
|
||||
|
||||
---
|
||||
|
||||
*最后更新: 2026-04-14*
|
||||
|
||||
@@ -1,64 +1,64 @@
|
||||
---
|
||||
title: CTP Topic 58 AWS EC2 image builder
|
||||
type: cloud-learning
|
||||
source-type: video
|
||||
category: DevOps & SRE/01_AWS-Landing-Zone
|
||||
tags:
|
||||
- AWS
|
||||
- EC2
|
||||
- Image-Builder
|
||||
- CTP
|
||||
date-added: 2026-04-14
|
||||
video-source: nas:///volume2/work/Public Cloud Learning Sessions/CTP _ Topic 58_ AWS EC2 image builder.mp4
|
||||
audio-source: ""
|
||||
status: summarized (Gemini 摘要)
|
||||
---
|
||||
|
||||
# CTP Topic 58 AWS EC2 image builder
|
||||
|
||||
**Source:** NAS `/volume2/work/Public Cloud Learning Sessions/CTP _ Topic 58_ AWS EC2 image builder.mp4`
|
||||
|
||||
**Type:** VIDEO | **Category:** 01_AWS-Landing-Zone
|
||||
|
||||
**Status:** 🟡 Awaiting Whisper transcription → Summary
|
||||
|
||||
---
|
||||
|
||||
## 摘要
|
||||
|
||||
> ## AWS EC2 Image Builder
|
||||
|
||||
AWS EC2 Image Builder is a managed AWS service to automate the creation, management, and distribution of AMIs and Docker images using components like image pipelines, image recipes, and infrastructure configurations. Image pipelines define how AMIs are published, including installations, security hardening, and distribution schedules.
|
||||
|
||||
Image recipes, written in YAML, define the source AMI for creating an output AMI, while container recipes support Docker images. Components are individual steps executed within the source AMI, such as installing packages or running shell commands. *A component is basically just a particular step that you want to execute in order to achieve the output AMI.* Infrastructure configurations define instance attributes like instance type, VPC, subnet, and security groups. Distribution settings manage the distribution of AMIs across different regions and accounts.
|
||||
|
||||
The current AMI publishing process involves OS-specific hardening scripts in GitLab repositories and Jenkins pipelines launching Packer to build and share images. Some product teams have developed parallel image bakeries, while others use manual processes with limited automation. The current approach has shortcomings, including longer turnaround times for modifications, AMI compatibility issues across landing zones, and limited automation in manual image bakeries. *Due to these limitations and these things what happens is eventually the product teams try to cater to their requirements by developing some kind of workflow or CI CD pipelines wherein they consume that CCOE AMI and they try to update or install whatever packages they require for their requirement or try to fulfill the functionalities which were lacking in the base AMI.*
|
||||
|
||||
Image Builder offers advantages such as increased productivity through automation, efficient image testing during the build process, incorporation of hardening standards, and easy image distribution. It integrates with AWS Organizations and AWS RAM for distributing AMIs across managed accounts. Supported OSes include Amazon Linux, Windows Server, Red Hat Linux, CentOS, Ubuntu, and SUSE, with the list expected to expand.
|
||||
|
||||
A POC has implemented end-to-end pipelines for CentOS 7 and Ubuntu 18, using CCOE hardening scripts converted into individual components. Terraform modules are in place for creating resources, with a consolidated module simplifying consumption for product teams. Testing scenarios are incorporated within components to validate execution, and AWS Inspector is integrated for AMI scanning against security standards. A Lambda workflow triggers scans, sends email notifications, and uploads reports to S3, maintaining a historical data of published AMIs. Qualys scan integration is under evaluation.
|
||||
|
||||
Product groups can use a service module to add components to the golden AMI. A component is a script, and components should be added in alphabetical order. The HCL file is used to create and manage components. Logs are published in CloudWatch. The image builder process requires approval, and the approval process is still under development.
|
||||
|
||||
|
||||
---
|
||||
|
||||
## 关键概念
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 行动项
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 相关视频
|
||||
|
||||
> 配对视频笔记链接（生成后填入）
|
||||
|
||||
---
|
||||
|
||||
*最后更新: 2026-04-14*
|
||||
---
|
||||
title: CTP Topic 58 AWS EC2 image builder
|
||||
type: cloud-learning
|
||||
source-type: video
|
||||
category: DevOps & SRE/01_AWS-Landing-Zone
|
||||
tags:
|
||||
- AWS
|
||||
- EC2
|
||||
- Image-Builder
|
||||
- CTP
|
||||
date-added: 2026-04-14
|
||||
video-source: nas:///volume2/work/Public Cloud Learning Sessions/CTP _ Topic 58_ AWS EC2 image builder.mp4
|
||||
audio-source: ""
|
||||
status: summarized (Gemini 摘要)
|
||||
---
|
||||
|
||||
# CTP Topic 58 AWS EC2 image builder
|
||||
|
||||
**Source:** NAS `/volume2/work/Public Cloud Learning Sessions/CTP _ Topic 58_ AWS EC2 image builder.mp4`
|
||||
|
||||
**Type:** VIDEO | **Category:** 01_AWS-Landing-Zone
|
||||
|
||||
**Status:** 🟡 Awaiting Whisper transcription → Summary
|
||||
|
||||
---
|
||||
|
||||
## 摘要
|
||||
|
||||
> ## AWS EC2 Image Builder
|
||||
|
||||
AWS EC2 Image Builder is a managed AWS service to automate the creation, management, and distribution of AMIs and Docker images using components like image pipelines, image recipes, and infrastructure configurations. Image pipelines define how AMIs are published, including installations, security hardening, and distribution schedules.
|
||||
|
||||
Image recipes, written in YAML, define the source AMI for creating an output AMI, while container recipes support Docker images. Components are individual steps executed within the source AMI, such as installing packages or running shell commands. *A component is basically just a particular step that you want to execute in order to achieve the output AMI.* Infrastructure configurations define instance attributes like instance type, VPC, subnet, and security groups. Distribution settings manage the distribution of AMIs across different regions and accounts.
|
||||
|
||||
The current AMI publishing process involves OS-specific hardening scripts in GitLab repositories and Jenkins pipelines launching Packer to build and share images. Some product teams have developed parallel image bakeries, while others use manual processes with limited automation. The current approach has shortcomings, including longer turnaround times for modifications, AMI compatibility issues across landing zones, and limited automation in manual image bakeries. *Due to these limitations and these things what happens is eventually the product teams try to cater to their requirements by developing some kind of workflow or CI CD pipelines wherein they consume that CCOE AMI and they try to update or install whatever packages they require for their requirement or try to fulfill the functionalities which were lacking in the base AMI.*
|
||||
|
||||
Image Builder offers advantages such as increased productivity through automation, efficient image testing during the build process, incorporation of hardening standards, and easy image distribution. It integrates with AWS Organizations and AWS RAM for distributing AMIs across managed accounts. Supported OSes include Amazon Linux, Windows Server, Red Hat Linux, CentOS, Ubuntu, and SUSE, with the list expected to expand.
|
||||
|
||||
A POC has implemented end-to-end pipelines for CentOS 7 and Ubuntu 18, using CCOE hardening scripts converted into individual components. Terraform modules are in place for creating resources, with a consolidated module simplifying consumption for product teams. Testing scenarios are incorporated within components to validate execution, and AWS Inspector is integrated for AMI scanning against security standards. A Lambda workflow triggers scans, sends email notifications, and uploads reports to S3, maintaining a historical data of published AMIs. Qualys scan integration is under evaluation.
|
||||
|
||||
Product groups can use a service module to add components to the golden AMI. A component is a script, and components should be added in alphabetical order. The HCL file is used to create and manage components. Logs are published in CloudWatch. The image builder process requires approval, and the approval process is still under development.
|
||||
|
||||
|
||||
---
|
||||
|
||||
## 关键概念
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 行动项
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 相关视频
|
||||
|
||||
> 配对视频笔记链接（生成后填入）
|
||||
|
||||
---
|
||||
|
||||
*最后更新: 2026-04-14*
|
||||
|
||||
@@ -1,51 +1,51 @@
|
||||
---
|
||||
title: CTP Topic 58 AWS EC2 image builder
|
||||
type: cloud-learning
|
||||
source-type: video
|
||||
category: DevOps & SRE/01_AWS-Landing-Zone
|
||||
tags:
|
||||
- AWS
|
||||
- EC2
|
||||
- Image-Builder
|
||||
- CTP
|
||||
date-added: 2026-04-14
|
||||
video-source: nas:///volume2/work/Public Cloud Learning Sessions/CTP _ Topic 58_ AWS EC2 image builder.mp4
|
||||
audio-source: ""
|
||||
status: raw
|
||||
---
|
||||
|
||||
# CTP Topic 58 AWS EC2 image builder
|
||||
|
||||
**Source:** NAS `/volume2/work/Public Cloud Learning Sessions/CTP _ Topic 58_ AWS EC2 image builder.mp4`
|
||||
|
||||
**Type:** VIDEO | **Category:** 01_AWS-Landing-Zone
|
||||
|
||||
**Status:** 🟡 Awaiting Whisper transcription → Summary
|
||||
|
||||
---
|
||||
|
||||
## 摘要
|
||||
|
||||
> 待转录后由 LLM 生成
|
||||
|
||||
---
|
||||
|
||||
## 关键概念
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 行动项
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 相关视频
|
||||
|
||||
> 配对视频笔记链接（生成后填入）
|
||||
|
||||
---
|
||||
|
||||
*最后更新: 2026-04-14*
|
||||
---
|
||||
title: CTP Topic 58 AWS EC2 image builder
|
||||
type: cloud-learning
|
||||
source-type: video
|
||||
category: DevOps & SRE/01_AWS-Landing-Zone
|
||||
tags:
|
||||
- AWS
|
||||
- EC2
|
||||
- Image-Builder
|
||||
- CTP
|
||||
date-added: 2026-04-14
|
||||
video-source: nas:///volume2/work/Public Cloud Learning Sessions/CTP _ Topic 58_ AWS EC2 image builder.mp4
|
||||
audio-source: ""
|
||||
status: raw
|
||||
---
|
||||
|
||||
# CTP Topic 58 AWS EC2 image builder
|
||||
|
||||
**Source:** NAS `/volume2/work/Public Cloud Learning Sessions/CTP _ Topic 58_ AWS EC2 image builder.mp4`
|
||||
|
||||
**Type:** VIDEO | **Category:** 01_AWS-Landing-Zone
|
||||
|
||||
**Status:** 🟡 Awaiting Whisper transcription → Summary
|
||||
|
||||
---
|
||||
|
||||
## 摘要
|
||||
|
||||
> 待转录后由 LLM 生成
|
||||
|
||||
---
|
||||
|
||||
## 关键概念
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 行动项
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 相关视频
|
||||
|
||||
> 配对视频笔记链接（生成后填入）
|
||||
|
||||
---
|
||||
|
||||
*最后更新: 2026-04-14*
|
||||
|
||||
@@ -1,92 +1,92 @@
|
||||
---
|
||||
title: CTP Topic 66 Exposing the differences between PostgreSQL RDS and Aurora
|
||||
type: cloud-learning
|
||||
source-type: video
|
||||
category: DevOps & SRE/01_AWS-Landing-Zone
|
||||
tags:
|
||||
- AWS
|
||||
- RDS
|
||||
- Aurora
|
||||
- PostgreSQL
|
||||
- CTP
|
||||
date-added: 2026-04-14
|
||||
video-source: nas:///volume2/work/Public Cloud Learning Sessions/CTP _ Topic 66_ Exposing the differences between PostgreSQL RDS and Aurora.mp4
|
||||
audio-source: ""
|
||||
status: summarized (Gemini 摘要)
|
||||
---
|
||||
|
||||
# CTP Topic 66 Exposing the differences between PostgreSQL RDS and Aurora
|
||||
|
||||
**Source:** NAS `/volume2/work/Public Cloud Learning Sessions/CTP _ Topic 66_ Exposing the differences between PostgreSQL RDS and Aurora.mp4`
|
||||
|
||||
**Type:** VIDEO | **Category:** 01_AWS-Landing-Zone
|
||||
|
||||
**Status:** 🟡 Awaiting Whisper transcription → Summary
|
||||
|
||||
---
|
||||
|
||||
## 摘要
|
||||
|
||||
> ## RDS vs. Aurora: Key Differences
|
||||
|
||||
Greg Klau presented a detailed comparison of PostgreSQL on Amazon RDS and Aurora, focusing on performance, cost, and use cases. The session covered choosing between the two, running blue-green and cross-region operations, monitoring, and network performance tweaks for high availability.
|
||||
|
||||
### Key Differences and Considerations
|
||||
|
||||
* **Minimum Size and Cost:** RDS offers smaller, cheaper instances suitable for small databases, while Aurora has a higher minimum size and cost due to its architecture.
|
||||
* **Maximum Size and Performance:** Aurora scales to larger databases and offers better IO performance, making it suitable for databases exceeding 10-20 terabytes.
|
||||
* **Auto Scaling:** Aurora offers auto-scaling (Serverless v2) but with limitations on instance shapes, versions, and regions.
|
||||
* **Recovery Time Objective (RTO):** Aurora boasts a 30-second RTO, compared to RDS's two minutes in the event of an AZ failure.
|
||||
* **Storage Flexibility:** RDS provides more storage options (GP2, GP3, provisioned IOPS, magnetic), while Aurora charges per IO.
|
||||
* *With RDS, you get to choose multiple different storage mechanisms.*
|
||||
* *Aurora IO is generally unbounded because they're motivated to give you as much IO as you can consume because they're charging you per IO.*
|
||||
|
||||
### Architectural Comparison
|
||||
|
||||
* **RDS:** Uses compute with attached storage (EBS). Multi-AZ setup involves another compute and storage node for failover. Replication across regions is asynchronous.
|
||||
* **Aurora:** Employs six EBS volumes across three availability zones, managed by Amazon. Adding compute uses the same cluster volume, avoiding data replication for read replicas. Aurora Global allows multi-region setups with asynchronous replication.
|
||||
* *With Aurora, you get six EBS volumes. They're spread across three availability zones.*
|
||||
* **Endpoints:** RDS has one endpoint per cluster, while Aurora has separate writer and reader endpoints.
|
||||
|
||||
### Database Switchover and Failover
|
||||
|
||||
* **RDS:** Requires blocking access, forcing a new primary, destroying the old cluster, and rebuilding it as a standby.
|
||||
* **Aurora:** Allows clean, managed switchovers using Aurora Global, without re-replication. Failover involves promoting a secondary region and re-adding the failed region as a new global cluster after it recovers.
|
||||
|
||||
### Blue-Green Deployments (Aurora MySQL Only)
|
||||
|
||||
* Aurora MySQL supports blue-green deployments for major version upgrades, creating a duplicate environment for testing before switching over. This involves logical replication to a green environment, with guardrails to prevent data loss.
|
||||
|
||||
### Monitoring
|
||||
|
||||
* Both RDS and Aurora offer monitoring options via CloudWatch, Grafana, and Performance Insights. Performance Insights provides a view of database load, query performance, and wait times.
|
||||
* Aurora utilizes free local storage (ephemeral SSD) for temporary work, which is fixed per instance type. RDS uses EBS for temporary storage.
|
||||
|
||||
### High Availability Performance Tweaks
|
||||
|
||||
* Lower DNS time to live (TTL) to one second for faster failover.
|
||||
* Adjust TCP Keep-Alive settings to detect database failures quickly.
|
||||
* Use JDBC connection string overloading with reader and writer endpoints for resilience.
|
||||
|
||||
|
||||
---
|
||||
|
||||
## 关键概念
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 行动项
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 相关视频
|
||||
|
||||
> 配对视频笔记链接（生成后填入）
|
||||
|
||||
---
|
||||
|
||||
*最后更新: 2026-04-14*
|
||||
---
|
||||
title: CTP Topic 66 Exposing the differences between PostgreSQL RDS and Aurora
|
||||
type: cloud-learning
|
||||
source-type: video
|
||||
category: DevOps & SRE/01_AWS-Landing-Zone
|
||||
tags:
|
||||
- AWS
|
||||
- RDS
|
||||
- Aurora
|
||||
- PostgreSQL
|
||||
- CTP
|
||||
date-added: 2026-04-14
|
||||
video-source: nas:///volume2/work/Public Cloud Learning Sessions/CTP _ Topic 66_ Exposing the differences between PostgreSQL RDS and Aurora.mp4
|
||||
audio-source: ""
|
||||
status: summarized (Gemini 摘要)
|
||||
---
|
||||
|
||||
# CTP Topic 66 Exposing the differences between PostgreSQL RDS and Aurora
|
||||
|
||||
**Source:** NAS `/volume2/work/Public Cloud Learning Sessions/CTP _ Topic 66_ Exposing the differences between PostgreSQL RDS and Aurora.mp4`
|
||||
|
||||
**Type:** VIDEO | **Category:** 01_AWS-Landing-Zone
|
||||
|
||||
**Status:** 🟡 Awaiting Whisper transcription → Summary
|
||||
|
||||
---
|
||||
|
||||
## 摘要
|
||||
|
||||
> ## RDS vs. Aurora: Key Differences
|
||||
|
||||
Greg Klau presented a detailed comparison of PostgreSQL on Amazon RDS and Aurora, focusing on performance, cost, and use cases. The session covered choosing between the two, running blue-green and cross-region operations, monitoring, and network performance tweaks for high availability.
|
||||
|
||||
### Key Differences and Considerations
|
||||
|
||||
* **Minimum Size and Cost:** RDS offers smaller, cheaper instances suitable for small databases, while Aurora has a higher minimum size and cost due to its architecture.
|
||||
* **Maximum Size and Performance:** Aurora scales to larger databases and offers better IO performance, making it suitable for databases exceeding 10-20 terabytes.
|
||||
* **Auto Scaling:** Aurora offers auto-scaling (Serverless v2) but with limitations on instance shapes, versions, and regions.
|
||||
* **Recovery Time Objective (RTO):** Aurora boasts a 30-second RTO, compared to RDS's two minutes in the event of an AZ failure.
|
||||
* **Storage Flexibility:** RDS provides more storage options (GP2, GP3, provisioned IOPS, magnetic), while Aurora charges per IO.
|
||||
* *With RDS, you get to choose multiple different storage mechanisms.*
|
||||
* *Aurora IO is generally unbounded because they're motivated to give you as much IO as you can consume because they're charging you per IO.*
|
||||
|
||||
### Architectural Comparison
|
||||
|
||||
* **RDS:** Uses compute with attached storage (EBS). Multi-AZ setup involves another compute and storage node for failover. Replication across regions is asynchronous.
|
||||
* **Aurora:** Employs six EBS volumes across three availability zones, managed by Amazon. Adding compute uses the same cluster volume, avoiding data replication for read replicas. Aurora Global allows multi-region setups with asynchronous replication.
|
||||
* *With Aurora, you get six EBS volumes. They're spread across three availability zones.*
|
||||
* **Endpoints:** RDS has one endpoint per cluster, while Aurora has separate writer and reader endpoints.
|
||||
|
||||
### Database Switchover and Failover
|
||||
|
||||
* **RDS:** Requires blocking access, forcing a new primary, destroying the old cluster, and rebuilding it as a standby.
|
||||
* **Aurora:** Allows clean, managed switchovers using Aurora Global, without re-replication. Failover involves promoting a secondary region and re-adding the failed region as a new global cluster after it recovers.
|
||||
|
||||
### Blue-Green Deployments (Aurora MySQL Only)
|
||||
|
||||
* Aurora MySQL supports blue-green deployments for major version upgrades, creating a duplicate environment for testing before switching over. This involves logical replication to a green environment, with guardrails to prevent data loss.
|
||||
|
||||
### Monitoring
|
||||
|
||||
* Both RDS and Aurora offer monitoring options via CloudWatch, Grafana, and Performance Insights. Performance Insights provides a view of database load, query performance, and wait times.
|
||||
* Aurora utilizes free local storage (ephemeral SSD) for temporary work, which is fixed per instance type. RDS uses EBS for temporary storage.
|
||||
|
||||
### High Availability Performance Tweaks
|
||||
|
||||
* Lower DNS time to live (TTL) to one second for faster failover.
|
||||
* Adjust TCP Keep-Alive settings to detect database failures quickly.
|
||||
* Use JDBC connection string overloading with reader and writer endpoints for resilience.
|
||||
|
||||
|
||||
---
|
||||
|
||||
## 关键概念
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 行动项
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 相关视频
|
||||
|
||||
> 配对视频笔记链接（生成后填入）
|
||||
|
||||
---
|
||||
|
||||
*最后更新: 2026-04-14*
|
||||
|
||||
@@ -1,52 +1,52 @@
|
||||
---
|
||||
title: CTP Topic 66 Exposing the differences between PostgreSQL RDS and Aurora
|
||||
type: cloud-learning
|
||||
source-type: video
|
||||
category: DevOps & SRE/01_AWS-Landing-Zone
|
||||
tags:
|
||||
- AWS
|
||||
- RDS
|
||||
- Aurora
|
||||
- PostgreSQL
|
||||
- CTP
|
||||
date-added: 2026-04-14
|
||||
video-source: nas:///volume2/work/Public Cloud Learning Sessions/CTP _ Topic 66_ Exposing the differences between PostgreSQL RDS and Aurora.mp4
|
||||
audio-source: ""
|
||||
status: raw
|
||||
---
|
||||
|
||||
# CTP Topic 66 Exposing the differences between PostgreSQL RDS and Aurora
|
||||
|
||||
**Source:** NAS `/volume2/work/Public Cloud Learning Sessions/CTP _ Topic 66_ Exposing the differences between PostgreSQL RDS and Aurora.mp4`
|
||||
|
||||
**Type:** VIDEO | **Category:** 01_AWS-Landing-Zone
|
||||
|
||||
**Status:** 🟡 Awaiting Whisper transcription → Summary
|
||||
|
||||
---
|
||||
|
||||
## 摘要
|
||||
|
||||
> 待转录后由 LLM 生成
|
||||
|
||||
---
|
||||
|
||||
## 关键概念
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 行动项
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 相关视频
|
||||
|
||||
> 配对视频笔记链接（生成后填入）
|
||||
|
||||
---
|
||||
|
||||
*最后更新: 2026-04-14*
|
||||
---
|
||||
title: CTP Topic 66 Exposing the differences between PostgreSQL RDS and Aurora
|
||||
type: cloud-learning
|
||||
source-type: video
|
||||
category: DevOps & SRE/01_AWS-Landing-Zone
|
||||
tags:
|
||||
- AWS
|
||||
- RDS
|
||||
- Aurora
|
||||
- PostgreSQL
|
||||
- CTP
|
||||
date-added: 2026-04-14
|
||||
video-source: nas:///volume2/work/Public Cloud Learning Sessions/CTP _ Topic 66_ Exposing the differences between PostgreSQL RDS and Aurora.mp4
|
||||
audio-source: ""
|
||||
status: raw
|
||||
---
|
||||
|
||||
# CTP Topic 66 Exposing the differences between PostgreSQL RDS and Aurora
|
||||
|
||||
**Source:** NAS `/volume2/work/Public Cloud Learning Sessions/CTP _ Topic 66_ Exposing the differences between PostgreSQL RDS and Aurora.mp4`
|
||||
|
||||
**Type:** VIDEO | **Category:** 01_AWS-Landing-Zone
|
||||
|
||||
**Status:** 🟡 Awaiting Whisper transcription → Summary
|
||||
|
||||
---
|
||||
|
||||
## 摘要
|
||||
|
||||
> 待转录后由 LLM 生成
|
||||
|
||||
---
|
||||
|
||||
## 关键概念
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 行动项
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 相关视频
|
||||
|
||||
> 配对视频笔记链接（生成后填入）
|
||||
|
||||
---
|
||||
|
||||
*最后更新: 2026-04-14*
|
||||
|
||||
@@ -1,60 +1,60 @@
|
||||
---
|
||||
title: CTP Topic 68 Introduction to Redshift
|
||||
type: cloud-learning
|
||||
source-type: video
|
||||
category: DevOps & SRE/01_AWS-Landing-Zone
|
||||
tags:
|
||||
- AWS
|
||||
- Redshift
|
||||
- Data-Warehouse
|
||||
- CTP
|
||||
date-added: 2026-04-14
|
||||
video-source: nas:///volume2/work/Public Cloud Learning Sessions/CTP _ Topic 68_ Introduction to Redshift.mp4
|
||||
audio-source: ""
|
||||
status: summarized (Gemini 摘要)
|
||||
---
|
||||
|
||||
# CTP Topic 68 Introduction to Redshift
|
||||
|
||||
**Source:** NAS `/volume2/work/Public Cloud Learning Sessions/CTP _ Topic 68_ Introduction to Redshift.mp4`
|
||||
|
||||
**Type:** VIDEO | **Category:** 01_AWS-Landing-Zone
|
||||
|
||||
**Status:** 🟡 Awaiting Whisper transcription → Summary
|
||||
|
||||
---
|
||||
|
||||
## 摘要
|
||||
|
||||
> ## AWS Redshift Architecture and Components
|
||||
|
||||
This learning session covers AWS Redshift, focusing on its architecture, management, and key components. The session aims to provide a foundational understanding of Redshift, including its features like columnar operations, row-based operations, MPP (Massively Parallel Processing), data compression, and the significance of distinct and hot keys.
|
||||
|
||||
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.* It supports online analytical processing (OLAP) and offers advantages such as easy installation, maintenance of backups, point-in-time recovery, and cross-region disaster recovery.
|
||||
|
||||
Redshift architecture involves client applications communicating with Redshift clusters via JDBC and ODBC drivers, connecting to a leader node. The leader node manages schema, warehouse metadata, and query planning, distributing instructions to compute nodes. Compute nodes, determined by the instance type, execute queries across slices, processing data and returning results to the leader node. *The leader node then stores results in buffers for quick retrieval, enhancing performance.* Instance types include dense compute, dense storage, and RA3, each offering varying levels of compute power, RAM, and storage capacity. RA3 is noted for its cost-effectiveness and large storage capacity, utilizing AWS-managed NVMe storage.
|
||||
|
||||
Key features of Redshift include MPP, which enables parallel processing of queries across multiple compute nodes, improving query speed and response times. Data storage can be columnar or row-based; columnar storage is optimized for data warehouse operations due to faster performance and efficient memory usage. Data compression techniques, including LZO, further enhance performance by reducing data size. The sort key and dist key play a crucial role in optimizing queries and managing data distribution across compute nodes.
|
||||
|
||||
|
||||
---
|
||||
|
||||
## 关键概念
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 行动项
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 相关视频
|
||||
|
||||
> 配对视频笔记链接（生成后填入）
|
||||
|
||||
---
|
||||
|
||||
*最后更新: 2026-04-14*
|
||||
---
|
||||
title: CTP Topic 68 Introduction to Redshift
|
||||
type: cloud-learning
|
||||
source-type: video
|
||||
category: DevOps & SRE/01_AWS-Landing-Zone
|
||||
tags:
|
||||
- AWS
|
||||
- Redshift
|
||||
- Data-Warehouse
|
||||
- CTP
|
||||
date-added: 2026-04-14
|
||||
video-source: nas:///volume2/work/Public Cloud Learning Sessions/CTP _ Topic 68_ Introduction to Redshift.mp4
|
||||
audio-source: ""
|
||||
status: summarized (Gemini 摘要)
|
||||
---
|
||||
|
||||
# CTP Topic 68 Introduction to Redshift
|
||||
|
||||
**Source:** NAS `/volume2/work/Public Cloud Learning Sessions/CTP _ Topic 68_ Introduction to Redshift.mp4`
|
||||
|
||||
**Type:** VIDEO | **Category:** 01_AWS-Landing-Zone
|
||||
|
||||
**Status:** 🟡 Awaiting Whisper transcription → Summary
|
||||
|
||||
---
|
||||
|
||||
## 摘要
|
||||
|
||||
> ## AWS Redshift Architecture and Components
|
||||
|
||||
This learning session covers AWS Redshift, focusing on its architecture, management, and key components. The session aims to provide a foundational understanding of Redshift, including its features like columnar operations, row-based operations, MPP (Massively Parallel Processing), data compression, and the significance of distinct and hot keys.
|
||||
|
||||
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.* It supports online analytical processing (OLAP) and offers advantages such as easy installation, maintenance of backups, point-in-time recovery, and cross-region disaster recovery.
|
||||
|
||||
Redshift architecture involves client applications communicating with Redshift clusters via JDBC and ODBC drivers, connecting to a leader node. The leader node manages schema, warehouse metadata, and query planning, distributing instructions to compute nodes. Compute nodes, determined by the instance type, execute queries across slices, processing data and returning results to the leader node. *The leader node then stores results in buffers for quick retrieval, enhancing performance.* Instance types include dense compute, dense storage, and RA3, each offering varying levels of compute power, RAM, and storage capacity. RA3 is noted for its cost-effectiveness and large storage capacity, utilizing AWS-managed NVMe storage.
|
||||
|
||||
Key features of Redshift include MPP, which enables parallel processing of queries across multiple compute nodes, improving query speed and response times. Data storage can be columnar or row-based; columnar storage is optimized for data warehouse operations due to faster performance and efficient memory usage. Data compression techniques, including LZO, further enhance performance by reducing data size. The sort key and dist key play a crucial role in optimizing queries and managing data distribution across compute nodes.
|
||||
|
||||
|
||||
---
|
||||
|
||||
## 关键概念
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 行动项
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 相关视频
|
||||
|
||||
> 配对视频笔记链接（生成后填入）
|
||||
|
||||
---
|
||||
|
||||
*最后更新: 2026-04-14*
|
||||
|
||||
@@ -1,51 +1,51 @@
|
||||
---
|
||||
title: CTP Topic 68 Introduction to Redshift
|
||||
type: cloud-learning
|
||||
source-type: video
|
||||
category: DevOps & SRE/01_AWS-Landing-Zone
|
||||
tags:
|
||||
- AWS
|
||||
- Redshift
|
||||
- Data-Warehouse
|
||||
- CTP
|
||||
date-added: 2026-04-14
|
||||
video-source: nas:///volume2/work/Public Cloud Learning Sessions/CTP _ Topic 68_ Introduction to Redshift.mp4
|
||||
audio-source: ""
|
||||
status: raw
|
||||
---
|
||||
|
||||
# CTP Topic 68 Introduction to Redshift
|
||||
|
||||
**Source:** NAS `/volume2/work/Public Cloud Learning Sessions/CTP _ Topic 68_ Introduction to Redshift.mp4`
|
||||
|
||||
**Type:** VIDEO | **Category:** 01_AWS-Landing-Zone
|
||||
|
||||
**Status:** 🟡 Awaiting Whisper transcription → Summary
|
||||
|
||||
---
|
||||
|
||||
## 摘要
|
||||
|
||||
> 待转录后由 LLM 生成
|
||||
|
||||
---
|
||||
|
||||
## 关键概念
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 行动项
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 相关视频
|
||||
|
||||
> 配对视频笔记链接（生成后填入）
|
||||
|
||||
---
|
||||
|
||||
*最后更新: 2026-04-14*
|
||||
---
|
||||
title: CTP Topic 68 Introduction to Redshift
|
||||
type: cloud-learning
|
||||
source-type: video
|
||||
category: DevOps & SRE/01_AWS-Landing-Zone
|
||||
tags:
|
||||
- AWS
|
||||
- Redshift
|
||||
- Data-Warehouse
|
||||
- CTP
|
||||
date-added: 2026-04-14
|
||||
video-source: nas:///volume2/work/Public Cloud Learning Sessions/CTP _ Topic 68_ Introduction to Redshift.mp4
|
||||
audio-source: ""
|
||||
status: raw
|
||||
---
|
||||
|
||||
# CTP Topic 68 Introduction to Redshift
|
||||
|
||||
**Source:** NAS `/volume2/work/Public Cloud Learning Sessions/CTP _ Topic 68_ Introduction to Redshift.mp4`
|
||||
|
||||
**Type:** VIDEO | **Category:** 01_AWS-Landing-Zone
|
||||
|
||||
**Status:** 🟡 Awaiting Whisper transcription → Summary
|
||||
|
||||
---
|
||||
|
||||
## 摘要
|
||||
|
||||
> 待转录后由 LLM 生成
|
||||
|
||||
---
|
||||
|
||||
## 关键概念
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 行动项
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 相关视频
|
||||
|
||||
> 配对视频笔记链接（生成后填入）
|
||||
|
||||
---
|
||||
|
||||
*最后更新: 2026-04-14*
|
||||
|
||||
@@ -1,97 +1,97 @@
|
||||
---
|
||||
title: CTP Topic 7 SaaS Landing Zone design
|
||||
type: cloud-learning
|
||||
source-type: video
|
||||
category: DevOps & SRE/01_AWS-Landing-Zone
|
||||
tags:
|
||||
- AWS
|
||||
- Landing-Zone
|
||||
- SaaS
|
||||
- CTP
|
||||
date-added: 2026-04-14
|
||||
video-source: nas:///volume2/work/Public Cloud Learning Sessions/CTP _ Topic 7_ SaaS Landing Zone design.mp4
|
||||
audio-source: ""
|
||||
status: summarized (Gemini 摘要)
|
||||
---
|
||||
|
||||
# CTP Topic 7 SaaS Landing Zone design
|
||||
|
||||
**Source:** NAS `/volume2/work/Public Cloud Learning Sessions/CTP _ Topic 7_ SaaS Landing Zone design.mp4`
|
||||
|
||||
**Type:** VIDEO | **Category:** 01_AWS-Landing-Zone
|
||||
|
||||
**Status:** 🟡 Awaiting Whisper transcription → Summary
|
||||
|
||||
---
|
||||
|
||||
## 摘要
|
||||
|
||||
> ## SAS Landing Zone Design
|
||||
|
||||
The session covers the high-level design for the new production SAS Landing Zone, emphasizing a single landing zone approach for all products to reduce overhead and costs, a departure from the per-product group (PG) landing zones used in dev labs. The design incorporates AWS accounts, Terraform modules, and TerraGrant for deployment.
|
||||
|
||||
Key components include core accounts (shared, logs, security), baseline accounts (network, DNS, Active Directory), shared services accounts (software factory, cyber, ARC site, monitoring), and product accounts.
|
||||
|
||||
*The SAS landing zone will use a single landing zone for all the product groups.*
|
||||
|
||||
### Core Accounts
|
||||
|
||||
These accounts are based on the grant work reference architecture and include:
|
||||
|
||||
* **Shared Account:** Hosts hardened AMIs and a master Jenkins server for managing deployments. The master Jenkins initiates Lambda functions within each account to trigger Jenkins slaves, enhancing security by preventing direct exposure of the master Jenkins to jobs or credentials.
|
||||
* **Logs Account:** A centralized account for logs from every account (CloudTrail, Config, Flowlogs), accessible primarily to the security team, with read access for products to their specific logs.
|
||||
* **Security Account:** Hosts IAM roles inherited within each account, with the ability for account owners to attach additional policies to restrict role usage.
|
||||
|
||||
### Baseline Accounts
|
||||
|
||||
These accounts are essential for product functionality and include:
|
||||
|
||||
* **Network Account:** Contains a regional transit gateway connecting all accounts, with a checkpoint appliance for monitoring traffic based on a tagging approach. Resources require specific tags to access destinations like the internet or on-prem networks.
|
||||
* **DNS Account:** Hosts Route 53, with each product having its own hosted zone for managing DNS records.
|
||||
* **Active Directory Account:** Includes two AD nodes for domain joining and controlling resource access.
|
||||
|
||||
### Shared Services Accounts
|
||||
|
||||
These accounts provide internal production services to product accounts:
|
||||
|
||||
* Software Factory accounts (45 hubs, Octane Hub, Artifactory).
|
||||
* Cyber account (Qalis).
|
||||
* ARC site account.
|
||||
* Monitoring account (OBM, potentially Sitescope).
|
||||
|
||||
### Product Accounts
|
||||
|
||||
Each product account features a public subnet for internet exposure via a load balancer and internet gateway, while workloads reside in private subnets. A web application firewall (WAF) monitors incoming traffic, and CloudFront is available as a CDN.
|
||||
|
||||
*The workload itself is going to be under private subnet.*
|
||||
|
||||
### Automation and Deployment
|
||||
|
||||
Terraform is used for automation, with each account having its own GitHub repository. Changes to Terraform code trigger Jenkins via a GitHub hook, initiating a deployment process through the management VPC, Lambda, and ECS cluster. A review process, including code review and plan output review, is implemented before applying changes, with staging environments used for testing before production deployment.
|
||||
|
||||
### Remote Access
|
||||
|
||||
Remote access is transitioning from Checkpoint VPN to Pulse VPN, requiring operators to use a VPN client and authenticate against the AD. Future plans involve SD1 replacing some network components.
|
||||
|
||||
|
||||
---
|
||||
|
||||
## 关键概念
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 行动项
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 相关视频
|
||||
|
||||
> 配对视频笔记链接（生成后填入）
|
||||
|
||||
---
|
||||
|
||||
*最后更新: 2026-04-14*
|
||||
---
|
||||
title: CTP Topic 7 SaaS Landing Zone design
|
||||
type: cloud-learning
|
||||
source-type: video
|
||||
category: DevOps & SRE/01_AWS-Landing-Zone
|
||||
tags:
|
||||
- AWS
|
||||
- Landing-Zone
|
||||
- SaaS
|
||||
- CTP
|
||||
date-added: 2026-04-14
|
||||
video-source: nas:///volume2/work/Public Cloud Learning Sessions/CTP _ Topic 7_ SaaS Landing Zone design.mp4
|
||||
audio-source: ""
|
||||
status: summarized (Gemini 摘要)
|
||||
---
|
||||
|
||||
# CTP Topic 7 SaaS Landing Zone design
|
||||
|
||||
**Source:** NAS `/volume2/work/Public Cloud Learning Sessions/CTP _ Topic 7_ SaaS Landing Zone design.mp4`
|
||||
|
||||
**Type:** VIDEO | **Category:** 01_AWS-Landing-Zone
|
||||
|
||||
**Status:** 🟡 Awaiting Whisper transcription → Summary
|
||||
|
||||
---
|
||||
|
||||
## 摘要
|
||||
|
||||
> ## SAS Landing Zone Design
|
||||
|
||||
The session covers the high-level design for the new production SAS Landing Zone, emphasizing a single landing zone approach for all products to reduce overhead and costs, a departure from the per-product group (PG) landing zones used in dev labs. The design incorporates AWS accounts, Terraform modules, and TerraGrant for deployment.
|
||||
|
||||
Key components include core accounts (shared, logs, security), baseline accounts (network, DNS, Active Directory), shared services accounts (software factory, cyber, ARC site, monitoring), and product accounts.
|
||||
|
||||
*The SAS landing zone will use a single landing zone for all the product groups.*
|
||||
|
||||
### Core Accounts
|
||||
|
||||
These accounts are based on the grant work reference architecture and include:
|
||||
|
||||
* **Shared Account:** Hosts hardened AMIs and a master Jenkins server for managing deployments. The master Jenkins initiates Lambda functions within each account to trigger Jenkins slaves, enhancing security by preventing direct exposure of the master Jenkins to jobs or credentials.
|
||||
* **Logs Account:** A centralized account for logs from every account (CloudTrail, Config, Flowlogs), accessible primarily to the security team, with read access for products to their specific logs.
|
||||
* **Security Account:** Hosts IAM roles inherited within each account, with the ability for account owners to attach additional policies to restrict role usage.
|
||||
|
||||
### Baseline Accounts
|
||||
|
||||
These accounts are essential for product functionality and include:
|
||||
|
||||
* **Network Account:** Contains a regional transit gateway connecting all accounts, with a checkpoint appliance for monitoring traffic based on a tagging approach. Resources require specific tags to access destinations like the internet or on-prem networks.
|
||||
* **DNS Account:** Hosts Route 53, with each product having its own hosted zone for managing DNS records.
|
||||
* **Active Directory Account:** Includes two AD nodes for domain joining and controlling resource access.
|
||||
|
||||
### Shared Services Accounts
|
||||
|
||||
These accounts provide internal production services to product accounts:
|
||||
|
||||
* Software Factory accounts (45 hubs, Octane Hub, Artifactory).
|
||||
* Cyber account (Qalis).
|
||||
* ARC site account.
|
||||
* Monitoring account (OBM, potentially Sitescope).
|
||||
|
||||
### Product Accounts
|
||||
|
||||
Each product account features a public subnet for internet exposure via a load balancer and internet gateway, while workloads reside in private subnets. A web application firewall (WAF) monitors incoming traffic, and CloudFront is available as a CDN.
|
||||
|
||||
*The workload itself is going to be under private subnet.*
|
||||
|
||||
### Automation and Deployment
|
||||
|
||||
Terraform is used for automation, with each account having its own GitHub repository. Changes to Terraform code trigger Jenkins via a GitHub hook, initiating a deployment process through the management VPC, Lambda, and ECS cluster. A review process, including code review and plan output review, is implemented before applying changes, with staging environments used for testing before production deployment.
|
||||
|
||||
### Remote Access
|
||||
|
||||
Remote access is transitioning from Checkpoint VPN to Pulse VPN, requiring operators to use a VPN client and authenticate against the AD. Future plans involve SD1 replacing some network components.
|
||||
|
||||
|
||||
---
|
||||
|
||||
## 关键概念
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 行动项
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 相关视频
|
||||
|
||||
> 配对视频笔记链接（生成后填入）
|
||||
|
||||
---
|
||||
|
||||
*最后更新: 2026-04-14*
|
||||
|
||||
@@ -1,51 +1,51 @@
|
||||
---
|
||||
title: CTP Topic 7 SaaS Landing Zone design
|
||||
type: cloud-learning
|
||||
source-type: video
|
||||
category: DevOps & SRE/01_AWS-Landing-Zone
|
||||
tags:
|
||||
- AWS
|
||||
- Landing-Zone
|
||||
- SaaS
|
||||
- CTP
|
||||
date-added: 2026-04-14
|
||||
video-source: nas:///volume2/work/Public Cloud Learning Sessions/CTP _ Topic 7_ SaaS Landing Zone design.mp4
|
||||
audio-source: ""
|
||||
status: raw
|
||||
---
|
||||
|
||||
# CTP Topic 7 SaaS Landing Zone design
|
||||
|
||||
**Source:** NAS `/volume2/work/Public Cloud Learning Sessions/CTP _ Topic 7_ SaaS Landing Zone design.mp4`
|
||||
|
||||
**Type:** VIDEO | **Category:** 01_AWS-Landing-Zone
|
||||
|
||||
**Status:** 🟡 Awaiting Whisper transcription → Summary
|
||||
|
||||
---
|
||||
|
||||
## 摘要
|
||||
|
||||
> 待转录后由 LLM 生成
|
||||
|
||||
---
|
||||
|
||||
## 关键概念
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 行动项
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 相关视频
|
||||
|
||||
> 配对视频笔记链接（生成后填入）
|
||||
|
||||
---
|
||||
|
||||
*最后更新: 2026-04-14*
|
||||
---
|
||||
title: CTP Topic 7 SaaS Landing Zone design
|
||||
type: cloud-learning
|
||||
source-type: video
|
||||
category: DevOps & SRE/01_AWS-Landing-Zone
|
||||
tags:
|
||||
- AWS
|
||||
- Landing-Zone
|
||||
- SaaS
|
||||
- CTP
|
||||
date-added: 2026-04-14
|
||||
video-source: nas:///volume2/work/Public Cloud Learning Sessions/CTP _ Topic 7_ SaaS Landing Zone design.mp4
|
||||
audio-source: ""
|
||||
status: raw
|
||||
---
|
||||
|
||||
# CTP Topic 7 SaaS Landing Zone design
|
||||
|
||||
**Source:** NAS `/volume2/work/Public Cloud Learning Sessions/CTP _ Topic 7_ SaaS Landing Zone design.mp4`
|
||||
|
||||
**Type:** VIDEO | **Category:** 01_AWS-Landing-Zone
|
||||
|
||||
**Status:** 🟡 Awaiting Whisper transcription → Summary
|
||||
|
||||
---
|
||||
|
||||
## 摘要
|
||||
|
||||
> 待转录后由 LLM 生成
|
||||
|
||||
---
|
||||
|
||||
## 关键概念
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 行动项
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 相关视频
|
||||
|
||||
> 配对视频笔记链接（生成后填入）
|
||||
|
||||
---
|
||||
|
||||
*最后更新: 2026-04-14*
|
||||
|
||||
@@ -1,65 +1,65 @@
|
||||
---
|
||||
title: CTP Topic 72 Implementing an Enterprise DR Strategy using AWS Backup
|
||||
type: cloud-learning
|
||||
source-type: video
|
||||
category: DevOps & SRE/01_AWS-Landing-Zone
|
||||
tags:
|
||||
- AWS
|
||||
- DR
|
||||
- Backup
|
||||
- Enterprise
|
||||
- CTP
|
||||
date-added: 2026-04-14
|
||||
video-source: nas:///volume2/work/Public Cloud Learning Sessions/CTP _ Topic 72_ Implementing an Enterprise DR Strategy using AWS Backup.mp4
|
||||
audio-source: ""
|
||||
status: summarized (Gemini 摘要)
|
||||
---
|
||||
|
||||
# CTP Topic 72 Implementing an Enterprise DR Strategy using AWS Backup
|
||||
|
||||
**Source:** NAS `/volume2/work/Public Cloud Learning Sessions/CTP _ Topic 72_ Implementing an Enterprise DR Strategy using AWS Backup.mp4`
|
||||
|
||||
**Type:** VIDEO | **Category:** 01_AWS-Landing-Zone
|
||||
|
||||
**Status:** 🟡 Awaiting Whisper transcription → Summary
|
||||
|
||||
---
|
||||
|
||||
## 摘要
|
||||
|
||||
> ## Implementing an Enterprise DR Strategy Using AWS Backup
|
||||
|
||||
Sabith from AWS discusses disaster recovery (DR) strategies using AWS Backup, differentiating between high availability and disaster recovery. He recaps basic concepts like RTO and RPO, introduces AWS Backup, and presents reference architectures.
|
||||
|
||||
*We should always be prepared for a situation that everything falls all the time.* The shared responsibility model defines AWS's and the customer's roles in ensuring a resilient cloud environment. Human errors, technical failures, and natural disasters are major categories to consider when creating DR plans.
|
||||
|
||||
High availability ensures a system performs its functions, measured by mean time between failures. Disaster recovery focuses on data loss prevention and recovery, while high availability focuses on system uptime and service availability.
|
||||
|
||||
Recovery Point Objective (RPO) defines the acceptable data loss, while Recovery Time Objective (RTO) defines the acceptable downtime. Architectural patterns range from multi-site active-active (minimal interruption, high cost) to backup and restore (lower cost, longer interruption). AWS Backup is a fully managed, policy-based backup service that simplifies data protection. It supports numerous resource types and integrates with AWS Organizations for cross-account backup copies.
|
||||
|
||||
AWS Backup uses backup plans to define what, when, and how to back up, storing recovery points in backup vaults. It integrates with IAM policies for access control and AWS Backup Audit Manager (BAM) for compliance reporting. AWS Backup integrates with underlying services through data plane and control plane integrations. Full backups capture all data, while incremental backups only capture changes since the last backup.
|
||||
|
||||
AWS Backup offers immutable recovery points, automated scalability, and compliance features. Vault Lock in compliance mode prevents even root users from deleting recovery points until their lifecycle ends, deterring ransomware. Customers often use a vault or bunker account for storing backup copies, separate from workload accounts, to protect against compromises. A forensic account can be used to regularly test recovery points and scan for malware.
|
||||
|
||||
|
||||
---
|
||||
|
||||
## 关键概念
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 行动项
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 相关视频
|
||||
|
||||
> 配对视频笔记链接（生成后填入）
|
||||
|
||||
---
|
||||
|
||||
*最后更新: 2026-04-14*
|
||||
---
|
||||
title: CTP Topic 72 Implementing an Enterprise DR Strategy using AWS Backup
|
||||
type: cloud-learning
|
||||
source-type: video
|
||||
category: DevOps & SRE/01_AWS-Landing-Zone
|
||||
tags:
|
||||
- AWS
|
||||
- DR
|
||||
- Backup
|
||||
- Enterprise
|
||||
- CTP
|
||||
date-added: 2026-04-14
|
||||
video-source: nas:///volume2/work/Public Cloud Learning Sessions/CTP _ Topic 72_ Implementing an Enterprise DR Strategy using AWS Backup.mp4
|
||||
audio-source: ""
|
||||
status: summarized (Gemini 摘要)
|
||||
---
|
||||
|
||||
# CTP Topic 72 Implementing an Enterprise DR Strategy using AWS Backup
|
||||
|
||||
**Source:** NAS `/volume2/work/Public Cloud Learning Sessions/CTP _ Topic 72_ Implementing an Enterprise DR Strategy using AWS Backup.mp4`
|
||||
|
||||
**Type:** VIDEO | **Category:** 01_AWS-Landing-Zone
|
||||
|
||||
**Status:** 🟡 Awaiting Whisper transcription → Summary
|
||||
|
||||
---
|
||||
|
||||
## 摘要
|
||||
|
||||
> ## Implementing an Enterprise DR Strategy Using AWS Backup
|
||||
|
||||
Sabith from AWS discusses disaster recovery (DR) strategies using AWS Backup, differentiating between high availability and disaster recovery. He recaps basic concepts like RTO and RPO, introduces AWS Backup, and presents reference architectures.
|
||||
|
||||
*We should always be prepared for a situation that everything falls all the time.* The shared responsibility model defines AWS's and the customer's roles in ensuring a resilient cloud environment. Human errors, technical failures, and natural disasters are major categories to consider when creating DR plans.
|
||||
|
||||
High availability ensures a system performs its functions, measured by mean time between failures. Disaster recovery focuses on data loss prevention and recovery, while high availability focuses on system uptime and service availability.
|
||||
|
||||
Recovery Point Objective (RPO) defines the acceptable data loss, while Recovery Time Objective (RTO) defines the acceptable downtime. Architectural patterns range from multi-site active-active (minimal interruption, high cost) to backup and restore (lower cost, longer interruption). AWS Backup is a fully managed, policy-based backup service that simplifies data protection. It supports numerous resource types and integrates with AWS Organizations for cross-account backup copies.
|
||||
|
||||
AWS Backup uses backup plans to define what, when, and how to back up, storing recovery points in backup vaults. It integrates with IAM policies for access control and AWS Backup Audit Manager (BAM) for compliance reporting. AWS Backup integrates with underlying services through data plane and control plane integrations. Full backups capture all data, while incremental backups only capture changes since the last backup.
|
||||
|
||||
AWS Backup offers immutable recovery points, automated scalability, and compliance features. Vault Lock in compliance mode prevents even root users from deleting recovery points until their lifecycle ends, deterring ransomware. Customers often use a vault or bunker account for storing backup copies, separate from workload accounts, to protect against compromises. A forensic account can be used to regularly test recovery points and scan for malware.
|
||||
|
||||
|
||||
---
|
||||
|
||||
## 关键概念
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 行动项
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 相关视频
|
||||
|
||||
> 配对视频笔记链接（生成后填入）
|
||||
|
||||
---
|
||||
|
||||
*最后更新: 2026-04-14*
|
||||
|
||||
@@ -1,52 +1,52 @@
|
||||
---
|
||||
title: CTP Topic 72 Implementing an Enterprise DR Strategy using AWS Backup
|
||||
type: cloud-learning
|
||||
source-type: video
|
||||
category: DevOps & SRE/01_AWS-Landing-Zone
|
||||
tags:
|
||||
- AWS
|
||||
- DR
|
||||
- Backup
|
||||
- Enterprise
|
||||
- CTP
|
||||
date-added: 2026-04-14
|
||||
video-source: nas:///volume2/work/Public Cloud Learning Sessions/CTP _ Topic 72_ Implementing an Enterprise DR Strategy using AWS Backup.mp4
|
||||
audio-source: ""
|
||||
status: raw
|
||||
---
|
||||
|
||||
# CTP Topic 72 Implementing an Enterprise DR Strategy using AWS Backup
|
||||
|
||||
**Source:** NAS `/volume2/work/Public Cloud Learning Sessions/CTP _ Topic 72_ Implementing an Enterprise DR Strategy using AWS Backup.mp4`
|
||||
|
||||
**Type:** VIDEO | **Category:** 01_AWS-Landing-Zone
|
||||
|
||||
**Status:** 🟡 Awaiting Whisper transcription → Summary
|
||||
|
||||
---
|
||||
|
||||
## 摘要
|
||||
|
||||
> 待转录后由 LLM 生成
|
||||
|
||||
---
|
||||
|
||||
## 关键概念
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 行动项
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 相关视频
|
||||
|
||||
> 配对视频笔记链接（生成后填入）
|
||||
|
||||
---
|
||||
|
||||
*最后更新: 2026-04-14*
|
||||
---
|
||||
title: CTP Topic 72 Implementing an Enterprise DR Strategy using AWS Backup
|
||||
type: cloud-learning
|
||||
source-type: video
|
||||
category: DevOps & SRE/01_AWS-Landing-Zone
|
||||
tags:
|
||||
- AWS
|
||||
- DR
|
||||
- Backup
|
||||
- Enterprise
|
||||
- CTP
|
||||
date-added: 2026-04-14
|
||||
video-source: nas:///volume2/work/Public Cloud Learning Sessions/CTP _ Topic 72_ Implementing an Enterprise DR Strategy using AWS Backup.mp4
|
||||
audio-source: ""
|
||||
status: raw
|
||||
---
|
||||
|
||||
# CTP Topic 72 Implementing an Enterprise DR Strategy using AWS Backup
|
||||
|
||||
**Source:** NAS `/volume2/work/Public Cloud Learning Sessions/CTP _ Topic 72_ Implementing an Enterprise DR Strategy using AWS Backup.mp4`
|
||||
|
||||
**Type:** VIDEO | **Category:** 01_AWS-Landing-Zone
|
||||
|
||||
**Status:** 🟡 Awaiting Whisper transcription → Summary
|
||||
|
||||
---
|
||||
|
||||
## 摘要
|
||||
|
||||
> 待转录后由 LLM 生成
|
||||
|
||||
---
|
||||
|
||||
## 关键概念
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 行动项
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 相关视频
|
||||
|
||||
> 配对视频笔记链接（生成后填入）
|
||||
|
||||
---
|
||||
|
||||
*最后更新: 2026-04-14*
|
||||
|
||||
@@ -1,57 +1,57 @@
|
||||
---
|
||||
title: CTP Topic 73 AWS Backup implementation of the Cloud Transformation Program
|
||||
type: cloud-learning
|
||||
source-type: video
|
||||
category: DevOps & SRE/01_AWS-Landing-Zone
|
||||
tags:
|
||||
- AWS
|
||||
- Backup
|
||||
- CTP
|
||||
date-added: 2026-04-14
|
||||
video-source: nas:///volume2/work/Public Cloud Learning Sessions/CTP _ Topic 73_ AWS Backup implementation of the Cloud Transformation Program.mp4
|
||||
audio-source: ""
|
||||
status: summarized (Gemini 摘要)
|
||||
---
|
||||
|
||||
# CTP Topic 73 AWS Backup implementation of the Cloud Transformation Program
|
||||
|
||||
**Source:** NAS `/volume2/work/Public Cloud Learning Sessions/CTP _ Topic 73_ AWS Backup implementation of the Cloud Transformation Program.mp4`
|
||||
|
||||
**Type:** VIDEO | **Category:** 01_AWS-Landing-Zone
|
||||
|
||||
**Status:** 🟡 Awaiting Whisper transcription → Summary
|
||||
|
||||
---
|
||||
|
||||
## 摘要
|
||||
|
||||
> The session covers the AWS backup implementation of the cloud transformation program, focusing on the CTP backup strategy, AWS backup audit manager, and the AWS backup module. The SRE core, SRE product, and architecture teams collaborated on a design to provide product groups with flexibility in their backup strategies.
|
||||
|
||||
Key points include the assumed backup policy for production workloads, which requires customer data to be backed up regularly (at least once in 24 hours) with a retention policy of at least 30 days, and two backup locations. AWS backup was adopted as the strategic tool for backup in AWS for the cloud transformation program to standardize backup processes. An SRE model was developed to allow product groups to create and control their own backups, aligned with the assumed backup policy, enabling independent backup and restore operations in their DRA accounts.
|
||||
|
||||
AWS backup was chosen because it is a native service managed by AWS, simplifying data protection at scale and supporting multiple AWS resources. It supports TAC based backup plans, cross-account and cross-region backups, immutability for backups, out-of-the-box audit reports and frameworks, and point-in-time recovery for S3 and RDS. The design involves taking initial backups within the source accounts and copying them to a remote account and region, ideally a dedicated DR account for each production workload account. *This keeps backups within the DR account for immediate restore, avoiding time-consuming data copies.* If a DR account is unavailable, a Databunker account can be used as a centralized account for storing backups. The SRE backup model simplifies the adoption of AWS backup by creating AWS backup plans, selections, local AWS backup vaults, KMSKN policies, additional vaults in the DR account, Enroll policies, lifecycle policies, SNS topic creations, audit reports, and optional point-in-time restore for SRE and RDS. *The SRE models were adjusted to optionally create custom KMS kits, which is a fundamental requirement for having a remote account and region for the AWS backup processes.*
|
||||
|
||||
The AWS backup audit manager provides out-of-the-box reports and compliance reports. Reports can be exported to an S3 bucket in CSV or JSON format, providing insights into the status of backups, resources backed up, creation date, recovery point, backup duration, and size. SNS notifications can be configured to receive alerts regarding the status of backups. The AWS backup audit manager framework includes controls that help evaluate backup practices, providing compliance reports. Controls include ensuring backup resources are protected by a backup plan, minimum frequency and retention, prevention of manual deletion of recovery points, encryption of recovery points, and scheduled cross-region and cross-account backups.
|
||||
|
||||
|
||||
---
|
||||
|
||||
## 关键概念
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 行动项
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 相关视频
|
||||
|
||||
> 配对视频笔记链接（生成后填入）
|
||||
|
||||
---
|
||||
|
||||
*最后更新: 2026-04-14*
|
||||
---
|
||||
title: CTP Topic 73 AWS Backup implementation of the Cloud Transformation Program
|
||||
type: cloud-learning
|
||||
source-type: video
|
||||
category: DevOps & SRE/01_AWS-Landing-Zone
|
||||
tags:
|
||||
- AWS
|
||||
- Backup
|
||||
- CTP
|
||||
date-added: 2026-04-14
|
||||
video-source: nas:///volume2/work/Public Cloud Learning Sessions/CTP _ Topic 73_ AWS Backup implementation of the Cloud Transformation Program.mp4
|
||||
audio-source: ""
|
||||
status: summarized (Gemini 摘要)
|
||||
---
|
||||
|
||||
# CTP Topic 73 AWS Backup implementation of the Cloud Transformation Program
|
||||
|
||||
**Source:** NAS `/volume2/work/Public Cloud Learning Sessions/CTP _ Topic 73_ AWS Backup implementation of the Cloud Transformation Program.mp4`
|
||||
|
||||
**Type:** VIDEO | **Category:** 01_AWS-Landing-Zone
|
||||
|
||||
**Status:** 🟡 Awaiting Whisper transcription → Summary
|
||||
|
||||
---
|
||||
|
||||
## 摘要
|
||||
|
||||
> The session covers the AWS backup implementation of the cloud transformation program, focusing on the CTP backup strategy, AWS backup audit manager, and the AWS backup module. The SRE core, SRE product, and architecture teams collaborated on a design to provide product groups with flexibility in their backup strategies.
|
||||
|
||||
Key points include the assumed backup policy for production workloads, which requires customer data to be backed up regularly (at least once in 24 hours) with a retention policy of at least 30 days, and two backup locations. AWS backup was adopted as the strategic tool for backup in AWS for the cloud transformation program to standardize backup processes. An SRE model was developed to allow product groups to create and control their own backups, aligned with the assumed backup policy, enabling independent backup and restore operations in their DRA accounts.
|
||||
|
||||
AWS backup was chosen because it is a native service managed by AWS, simplifying data protection at scale and supporting multiple AWS resources. It supports TAC based backup plans, cross-account and cross-region backups, immutability for backups, out-of-the-box audit reports and frameworks, and point-in-time recovery for S3 and RDS. The design involves taking initial backups within the source accounts and copying them to a remote account and region, ideally a dedicated DR account for each production workload account. *This keeps backups within the DR account for immediate restore, avoiding time-consuming data copies.* If a DR account is unavailable, a Databunker account can be used as a centralized account for storing backups. The SRE backup model simplifies the adoption of AWS backup by creating AWS backup plans, selections, local AWS backup vaults, KMSKN policies, additional vaults in the DR account, Enroll policies, lifecycle policies, SNS topic creations, audit reports, and optional point-in-time restore for SRE and RDS. *The SRE models were adjusted to optionally create custom KMS kits, which is a fundamental requirement for having a remote account and region for the AWS backup processes.*
|
||||
|
||||
The AWS backup audit manager provides out-of-the-box reports and compliance reports. Reports can be exported to an S3 bucket in CSV or JSON format, providing insights into the status of backups, resources backed up, creation date, recovery point, backup duration, and size. SNS notifications can be configured to receive alerts regarding the status of backups. The AWS backup audit manager framework includes controls that help evaluate backup practices, providing compliance reports. Controls include ensuring backup resources are protected by a backup plan, minimum frequency and retention, prevention of manual deletion of recovery points, encryption of recovery points, and scheduled cross-region and cross-account backups.
|
||||
|
||||
|
||||
---
|
||||
|
||||
## 关键概念
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 行动项
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 相关视频
|
||||
|
||||
> 配对视频笔记链接（生成后填入）
|
||||
|
||||
---
|
||||
|
||||
*最后更新: 2026-04-14*
|
||||
|
||||
@@ -1,50 +1,50 @@
|
||||
---
|
||||
title: CTP Topic 73 AWS Backup implementation of the Cloud Transformation Program
|
||||
type: cloud-learning
|
||||
source-type: video
|
||||
category: DevOps & SRE/01_AWS-Landing-Zone
|
||||
tags:
|
||||
- AWS
|
||||
- Backup
|
||||
- CTP
|
||||
date-added: 2026-04-14
|
||||
video-source: nas:///volume2/work/Public Cloud Learning Sessions/CTP _ Topic 73_ AWS Backup implementation of the Cloud Transformation Program.mp4
|
||||
audio-source: ""
|
||||
status: raw
|
||||
---
|
||||
|
||||
# CTP Topic 73 AWS Backup implementation of the Cloud Transformation Program
|
||||
|
||||
**Source:** NAS `/volume2/work/Public Cloud Learning Sessions/CTP _ Topic 73_ AWS Backup implementation of the Cloud Transformation Program.mp4`
|
||||
|
||||
**Type:** VIDEO | **Category:** 01_AWS-Landing-Zone
|
||||
|
||||
**Status:** 🟡 Awaiting Whisper transcription → Summary
|
||||
|
||||
---
|
||||
|
||||
## 摘要
|
||||
|
||||
> 待转录后由 LLM 生成
|
||||
|
||||
---
|
||||
|
||||
## 关键概念
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 行动项
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 相关视频
|
||||
|
||||
> 配对视频笔记链接（生成后填入）
|
||||
|
||||
---
|
||||
|
||||
*最后更新: 2026-04-14*
|
||||
---
|
||||
title: CTP Topic 73 AWS Backup implementation of the Cloud Transformation Program
|
||||
type: cloud-learning
|
||||
source-type: video
|
||||
category: DevOps & SRE/01_AWS-Landing-Zone
|
||||
tags:
|
||||
- AWS
|
||||
- Backup
|
||||
- CTP
|
||||
date-added: 2026-04-14
|
||||
video-source: nas:///volume2/work/Public Cloud Learning Sessions/CTP _ Topic 73_ AWS Backup implementation of the Cloud Transformation Program.mp4
|
||||
audio-source: ""
|
||||
status: raw
|
||||
---
|
||||
|
||||
# CTP Topic 73 AWS Backup implementation of the Cloud Transformation Program
|
||||
|
||||
**Source:** NAS `/volume2/work/Public Cloud Learning Sessions/CTP _ Topic 73_ AWS Backup implementation of the Cloud Transformation Program.mp4`
|
||||
|
||||
**Type:** VIDEO | **Category:** 01_AWS-Landing-Zone
|
||||
|
||||
**Status:** 🟡 Awaiting Whisper transcription → Summary
|
||||
|
||||
---
|
||||
|
||||
## 摘要
|
||||
|
||||
> 待转录后由 LLM 生成
|
||||
|
||||
---
|
||||
|
||||
## 关键概念
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 行动项
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 相关视频
|
||||
|
||||
> 配对视频笔记链接（生成后填入）
|
||||
|
||||
---
|
||||
|
||||
*最后更新: 2026-04-14*
|
||||
|
||||
@@ -1,26 +1,26 @@
|
||||
|
||||
|
||||
# learning sessions standard amis updates 20231205 160324 meeting recording 2
|
||||
|
||||
## Standard AMI Updates and Overview
|
||||
|
||||
The session provides a high-level overview and updates regarding Amazon Machine Images (AMIs). The standard AMIs are based on AWS AMIs but include OS hardening, the latest patches, and security updates. These AMIs also support domain joining, security tools, endpoint protection, access integration, a QALIS agent, SSM agent, DNS settings, Microsoft Edge for Windows AMIs, and GP3 EBS storage.
|
||||
|
||||
The AMIs are built, tested, and shared to all AWS accounts every two months, and are immediately available as private AMIs. Currently, 23 different AMIs are supported, including various versions of Amazon Linux, CentOS, Oracle Enterprise Linux, Red Hat, Rocky Linux, SUSE Linux, Ubuntu, and Windows servers. The latest three releases are available in 12 regions, and older AMIs are archived for 12 months.
|
||||
|
||||
The AMI release process follows a standard software release process, with changes developed on feature branches and merged into an integration branch. Jenkins multi-branch pipelines are used for building and testing the AMIs, including scripted tests and AWS Inspector. The publishing process involves copying the AMIs to different regions and sharing them to multiple organizations, with encryption and automatic creation of necessary grants. *The AMIs are then thrown through all of the test suites, and we'll see a couple of those as they come up in later slides, and then we verify that nothing seems to have regressed at that point.*
|
||||
|
||||
## Roadmap, Notifications, and End-of-Life
|
||||
|
||||
The current roadmap includes a future release of Amazon Linux 2023, X64, planned for January. New AMI requests must go through the demand pipeline and take approximately 60 days to release. AMI notifications are sent out with each release, including links to relevant documents and the portal. A change log is available in the portal, detailing the changes included in each release.
|
||||
|
||||
Several operating systems are reaching end-of-life, including CentOS 7 and Red Hat 7 in June 2024. *CentOS 7 will be replaced by Rocky Linux, which is already available as a standard AMI.* OpenSUSE Leap 15 and OEL 7 will reach end-of-life in December 2024.
|
||||
|
||||
## New Features and Validation
|
||||
|
||||
New features are injected into the release cycles based on various inputs, such as the migration from Trellix to Sentinel-1. The AMIs are designed to work across multiple landing zones and domain controller environments. The new landing zone uses secrets instead of parameter stores, and all automations now use cloud-based init. AMI utilization is monitored to track how frequently and how many AMIs are being used.
|
||||
|
||||
A robotic framework has been integrated to automate basic test cases and validations, reducing the validation time for one AMI from three-four days to 60 minutes. An SSM patching solution is available for long-running instances that cannot be refreshed frequently. The AMIs are validated and tested according to the highest security standards, with penetration testing conducted periodically.
|
||||
via model google/gemini-2.0-flash
|
||||
|
||||
Cached · google/gemini-2.0-flash
|
||||
|
||||
|
||||
# learning sessions standard amis updates 20231205 160324 meeting recording 2
|
||||
|
||||
## Standard AMI Updates and Overview
|
||||
|
||||
The session provides a high-level overview and updates regarding Amazon Machine Images (AMIs). The standard AMIs are based on AWS AMIs but include OS hardening, the latest patches, and security updates. These AMIs also support domain joining, security tools, endpoint protection, access integration, a QALIS agent, SSM agent, DNS settings, Microsoft Edge for Windows AMIs, and GP3 EBS storage.
|
||||
|
||||
The AMIs are built, tested, and shared to all AWS accounts every two months, and are immediately available as private AMIs. Currently, 23 different AMIs are supported, including various versions of Amazon Linux, CentOS, Oracle Enterprise Linux, Red Hat, Rocky Linux, SUSE Linux, Ubuntu, and Windows servers. The latest three releases are available in 12 regions, and older AMIs are archived for 12 months.
|
||||
|
||||
The AMI release process follows a standard software release process, with changes developed on feature branches and merged into an integration branch. Jenkins multi-branch pipelines are used for building and testing the AMIs, including scripted tests and AWS Inspector. The publishing process involves copying the AMIs to different regions and sharing them to multiple organizations, with encryption and automatic creation of necessary grants. *The AMIs are then thrown through all of the test suites, and we'll see a couple of those as they come up in later slides, and then we verify that nothing seems to have regressed at that point.*
|
||||
|
||||
## Roadmap, Notifications, and End-of-Life
|
||||
|
||||
The current roadmap includes a future release of Amazon Linux 2023, X64, planned for January. New AMI requests must go through the demand pipeline and take approximately 60 days to release. AMI notifications are sent out with each release, including links to relevant documents and the portal. A change log is available in the portal, detailing the changes included in each release.
|
||||
|
||||
Several operating systems are reaching end-of-life, including CentOS 7 and Red Hat 7 in June 2024. *CentOS 7 will be replaced by Rocky Linux, which is already available as a standard AMI.* OpenSUSE Leap 15 and OEL 7 will reach end-of-life in December 2024.
|
||||
|
||||
## New Features and Validation
|
||||
|
||||
New features are injected into the release cycles based on various inputs, such as the migration from Trellix to Sentinel-1. The AMIs are designed to work across multiple landing zones and domain controller environments. The new landing zone uses secrets instead of parameter stores, and all automations now use cloud-based init. AMI utilization is monitored to track how frequently and how many AMIs are being used.
|
||||
|
||||
A robotic framework has been integrated to automate basic test cases and validations, reducing the validation time for one AMI from three-four days to 60 minutes. An SSM patching solution is available for long-running instances that cannot be refreshed frequently. The AMIs are validated and tested according to the highest security standards, with penetration testing conducted periodically.
|
||||
via model google/gemini-2.0-flash
|
||||
|
||||
Cached · google/gemini-2.0-flash
|
||||
|
||||
@@ -1,51 +1,51 @@
|
||||
---
|
||||
title: "Learning Sessions Standard AMIs Updates - 20231205 160324-Meeting Recording (2)"
|
||||
type: cloud-learning
|
||||
source-type: video
|
||||
category: "DevOps & SRE/01_AWS-Landing-Zone"
|
||||
tags:
|
||||
- AWS
|
||||
- AMI
|
||||
- Updates
|
||||
- CTP
|
||||
date-added: 2026-04-14
|
||||
video-source: "nas:///volume2/work/Public Cloud Learning Sessions/Learning Sessions _ Standard AMIs Updates - 20231205_160324-Meeting Recording (2).mp4"
|
||||
audio-source: ""
|
||||
status: raw
|
||||
---
|
||||
|
||||
# Learning Sessions Standard AMIs Updates - 20231205 160324-Meeting Recording (2)
|
||||
|
||||
**Source:** NAS `/volume2/work/Public Cloud Learning Sessions/Learning Sessions _ Standard AMIs Updates - 20231205_160324-Meeting Recording (2).mp4`
|
||||
|
||||
**Type:** VIDEO | **Category:** 01_AWS-Landing-Zone
|
||||
|
||||
**Status:** 🟡 Awaiting Whisper transcription → Summary
|
||||
|
||||
---
|
||||
|
||||
## 摘要
|
||||
|
||||
> 待转录后由 LLM 生成
|
||||
|
||||
---
|
||||
|
||||
## 关键概念
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 行动项
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 相关视频
|
||||
|
||||
> 配对视频笔记链接（生成后填入）
|
||||
|
||||
---
|
||||
|
||||
*最后更新: 2026-04-14*
|
||||
---
|
||||
title: "Learning Sessions Standard AMIs Updates - 20231205 160324-Meeting Recording (2)"
|
||||
type: cloud-learning
|
||||
source-type: video
|
||||
category: "DevOps & SRE/01_AWS-Landing-Zone"
|
||||
tags:
|
||||
- AWS
|
||||
- AMI
|
||||
- Updates
|
||||
- CTP
|
||||
date-added: 2026-04-14
|
||||
video-source: "nas:///volume2/work/Public Cloud Learning Sessions/Learning Sessions _ Standard AMIs Updates - 20231205_160324-Meeting Recording (2).mp4"
|
||||
audio-source: ""
|
||||
status: raw
|
||||
---
|
||||
|
||||
# Learning Sessions Standard AMIs Updates - 20231205 160324-Meeting Recording (2)
|
||||
|
||||
**Source:** NAS `/volume2/work/Public Cloud Learning Sessions/Learning Sessions _ Standard AMIs Updates - 20231205_160324-Meeting Recording (2).mp4`
|
||||
|
||||
**Type:** VIDEO | **Category:** 01_AWS-Landing-Zone
|
||||
|
||||
**Status:** 🟡 Awaiting Whisper transcription → Summary
|
||||
|
||||
---
|
||||
|
||||
## 摘要
|
||||
|
||||
> 待转录后由 LLM 生成
|
||||
|
||||
---
|
||||
|
||||
## 关键概念
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 行动项
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 相关视频
|
||||
|
||||
> 配对视频笔记链接（生成后填入）
|
||||
|
||||
---
|
||||
|
||||
*最后更新: 2026-04-14*
|
||||
|
||||
Reference in New Issue
Block a user