Introducing the Snowflake and AWS Custom Lens for the AWS Well-Architected Framework

介绍 Snowflake 和 AWS 自定义镜像（Lens）用于 AWS Well-Architected Framework | AWS 架构博客

介绍 Snowflake 和 AWS 自定义镜像（Lens）用于 AWS Well-Architected Framework

在 AWS 上运行 Snowflake 意味着同时遵循两套不同的最佳实践：用于基础设施的 AWS Well-Architected 指南，以及用于计算、数据组织和治理的 Snowflake Well-Architected Framework 指南。如果没有统一的审查框架，安全控制将无法映射到 Snowflake 配置。当团队需要协调来自两个独立审查流程的指导时，生产就绪时间线会被拉长，而当审计证据来自不相关来源时，合规状态也变得难以展示。Snowflake 和 AWS 自定义 Well-Architected Framework 镜像填补了这一空白。

该镜像将 AWS Well-Architected 最佳实践和 Snowflake 指南整合到一个统一的审查体验中，其中包含的集成建议反映了这两个服务在生产环境中的组合方式。它会根据 AWS Well-Architected 的七个支柱（安全、可靠性、性能效率、成本优化、运营卓越和可持续性）评估您的架构。一次审查即可发现诸如错误配置的 Snowflake 网络策略与 Amazon 虚拟私有云（Amazon VPC）控制措施并存，或跨 Snowflake 虚拟仓库规模和 Amazon 弹性计算云（Amazon EC2）实例选择的成本效率问题。在本文中，我们将逐一介绍每个支柱、三个访问入口（AWS 管理控制台、Kiro 和 Snowflake Cortex Code）以及如何运行您的首次审查。

镜像中包含哪些内容？

Snowflake 和 AWS 自定义 WAF 镜像为联合 Snowflake-on-AWS 架构定义了七个支柱，这些支柱来源于七支柱的 AWS Well-Architected Framework 和五支柱的 Snowflake Well-Architected Framework。

支柱 1：安全与身份

在 AWS 上运行 Snowflake 的安全需要在两个不同的层面进行协调的身份和访问控制。在 AWS 基础设施方面，AWS 密钥管理服务（AWS KMS）、AWS IAM 身份中心和 Amazon VPC 配置等服务管理访问和加密。在 Snowflake 方面，网络策略、基于角色的访问控制（RBAC）层次结构以及 OAuth 或密钥对认证控制谁可以访问数据。下表映射了两个服务在安全领域（身份、网络、认证和授权）中最关键的领域，并提供集成建议，以确保这两个层面的对齐，从而帮助防止未经授权的访问。

| 领域 | AWS 指导 | Snowflake 指导 | 集成建议 | |------|----------|----------------|----------| | 网络安全 | Amazon VPC 设计、AWS PrivateLink 端点、AWS 服务端点、Amazon EC2 安全组 | 网络策略、IP 允许列表 | 在 Amazon VPC 和 Snowflake 之间使用 AWS PrivateLink；在 EC2 安全组上叠加 Snowflake 网络策略，以实现纵深防御 | | 身份和访问 | AWS 身份和访问管理（IAM）角色、联合身份、最小权限 | 数据库角色、角色层次结构、多因素认证（MFA） | 通过 AWS IAM 身份中心联合 Snowflake 认证；将身份提供商组映射到 Snowflake 数据库角色，以实现一致的 RBAC | | 认证 | 为人类 IAM 用户启用 MFA；通过 IAM 身份中心与企业 IdP 集成 | 服务账户使用 RSA 密钥对；人类使用 SAML SSO 或 OAuth；禁用密码认证 | |

将私钥存储在 AWS Secrets Manager 中；通过自动化进行轮换；通过 SAML 联邦实现两个系统的统一身份提供商（IdP）

授权

在组织级别设置服务控制策略作为硬性防护措施；为委派角色设置权限边界

具有继承关系的角色层次结构；为 SECURITYADMIN 授予与 SYSADMIN 分开的权限

通过工作负载身份联邦将 AWS IAM 角色 1:1 映射到 Snowflake 功能角色

第二支柱：数据治理与合规性

保护数据本身，无论访问者是谁，涵盖了两个互补的层面。在 AWS 基础设施方面，AWS KMS、AWS IAM Identity Center 和 Amazon Simple Storage Service（Amazon S3）生命周期策略管理静态数据的加密、分类和保留。在 Snowflake 方面，动态数据掩码、行访问策略、Tri-Secret Secure 和自动分类在查询层保护敏感数据。下表映射了两个系统中最关键的治理领域（分类、动态数据掩码、血缘关系、保留和合规性），并提供了保持端到端一致数据保护的集成建议。

数据保护

AWS KMS 客户管理密钥，Amazon S3 加密

动态掩码，行访问策略，

Tri-Secret Secure

使用

AWS KMS

与 Snowflake 结合实现双重控制加密；应用 Snowflake 掩码策略实现列级保护

审计与合规

AWS CloudTrail，AWS Config，AWS Security Hub

事件表，账户使用情况，访问历史，敏感数据分类

使用 Amazon S3 和 Amazon EventBridge 将 Snowflake 审计日志流式传输到 Amazon CloudWatch 或 Amazon OpenSearch Service，以实现统一的合规性监控。AWS 提供了支持合规性的功能；您的团队使用这些功能来支持和展示合规性。

行访问策略

AWS Lake Formation 行级过滤器，Amazon S3 访问点用于团队范围的访问

用于多租户隔离或区域数据驻留的行访问策略；基于角色的行可见性

在 Snowflake 中一次性定义行级安全性（单一执行点）；将 AWS 侧限制为管道服务账户

第三支柱：可靠性

在 AWS 上的 Snowflake 架构中，可靠性取决于两个系统在故障场景中的协调程度，从 AWS 基础设施中断到 Snowflake 服务可用性事件。下表涵盖了关键的可靠性领域，包括跨区域复制、故障转移配置和工作负载隔离，并提供了构建跨两个系统弹性架构的集成指导。

灾难恢复

多可用区（Multi-AZ）、跨区域复制、Amazon Route 53 故障转移

数据库复制、故障转移组、客户端重定向

将 Snowflake 跨区域复制配置到次要的 AWS 区域；使用 Snowflake 客户端重定向实现向次要区域的自动故障转移

数据持久性

Amazon S3 11 个 9 的持久性，版本控制

Time Travel，Fail-safe，

零拷贝克隆

将 Snowflake Time Travel 保留策略与 Amazon S3 版本控制策略对齐；使用

进行预部署测试，而无需存储开销

恢复目标

RTO 和 RPO 规划，备份策略

复制延迟监控，故障转移 SLA

定义联合的 RTO 和 RPO 目标，考虑 Snowflake 复制延迟和 AWS 基础设施恢复时间

第四支柱：性能优化

在 AWS 上运行 Snowflake 的性能效率需要在基础设施和应用层面进行调优。AWS 实例选择、网络吞吐量和存储配置直接影响 Snowflake 仓库的性能。特定于 Snowflake 的模式，如仓库规模、查询优化和聚类键，决定了计算资源的使用效率。下表涵盖了主要的性能领域，并为这两个层面提供了集成的建议。

计算规模

Amazon EC2 实例选择、自动扩展

仓库规模、多集群仓库、自动挂起

根据查询分析结果对 Snowflake 仓库进行合理配置；对于与应用层自动扩展相匹配的并发扩展，使用多集群仓库

数据组织

Amazon S3 分区、文件格式优化

聚类键、搜索优化、物化视图

优化 Amazon S3 中用于 Snowpipe 数据摄入的中间文件大小；在经常被过滤的列上应用聚类键，按基数从低到高排序。注意：这种排序方式是特定于 Snowflake 的微分区架构的。与传统数据库通常首先对高基数列进行索引不同，Snowflake 在聚类键中以最低基数的列开头时，可以实现更好的分区剪枝。

缓存与延迟

Amazon CloudFront、Amazon ElastiCache

结果缓存、仓库缓存、查询加速

设计查询模式以最大化 Snowflake 的结果缓存命中率；使用 Amazon ElastiCache 对频繁访问的 Snowflake 查询结果进行应用层缓存

第五支柱：成本优化与 FinOps

在 Snowflake 和 AWS 上的成本优化涉及两种不同的计费模型，您必须共同管理这两种模型。AWS 基础设施成本遵循消费和预留模型，而 Snowflake 的费用则由计算积分和存储决定。没有统一的视图，团队常常会为了优化一个应用而牺牲另一个应用。下表针对关键的成本领域，提供了减少两个计费模型支出的集成建议。

成本可见性

AWS Cost Explorer、AWS Budgets、AWS Cost and Usage Reports (CUR)

资源监控器、账户使用视图、积分跟踪

将 AWS Cost Explorer 数据与 Snowflake 积分消耗整合到统一的 FinOps 仪表板中；使用匹配的成本中心标签对资源进行标记

计算效率

AWS Savings Plans、Amazon EC2 Spot 实例

注意：Savings Plans 和 Spot 实例适用于客户管理的 AWS 计算（ETL 管道、应用层），这些计算用于向 Snowflake 提供数据，而不是 Snowflake 仓库计算本身。

自动挂起、仓库合理配置、无服务器功能

将 Snowflake 的容量承诺与 AWS Savings Plans 配合使用，以实现可预测的基础；对开发仓库积极使用自动挂起功能

存储效率

Amazon S3 生命周期策略、S3 智能分层

时间旅行保留优化、临时表

将 Snowflake 时间旅行保留（开发环境为 1 天，受监管数据为 90 天）与 Amazon S3 生命周期转换到 Amazon S3 Glacier 对齐

第六支柱：运营卓越

在 AWS 上实现 Snowflake 的运营卓越，意味着构建跨两个应用的可观测性、自动化和事件响应工作流程。Amazon CloudWatch、AWS Systems Manager 以及 Snowflake 的查询历史和任务监控各自提供了部分可见性，但一个运营良好的架构会将它们整合成一个连贯的运营视图。下表涵盖了核心运营领域，并提供了将两个应用作为单一系统进行管理的集成指导。

监控

• Amazon CloudWatch、AWS X-Ray、Amazon OpenSearch Service
• Snowsight 仪表板、账户使用情况、查询历史
• 使用 Amazon S3 集成将 Snowflake 指标导出到 Amazon CloudWatch，以创建统一的运营仪表板

自动化和 IaC

• AWS CloudFormation、AWS Cloud Development Kit (AWS CDK)、Terraform
• Snowflake Terraform 提供者、CI/CD 管道
• 在同一个 Terraform 状态中管理 Snowflake 对象和 AWS 基础设施；使用 CI/CD 管道进行数据库迁移工作流

事件响应

• Amazon EventBridge、Amazon Simple Notification Service (Amazon SNS)、AWS Lambda 自动修复
• 警报、资源监控、任务监控
• 通过通知集成和 Amazon SNS，从 Snowflake 资源监控警报触发 AWS Lambda 自动修复

第七支柱：可持续性

这是首个将可持续性支柱视为首要关注点的联合 ISV-AWS WAF 镜头。对于在 AWS 上运行的 Snowflake，可持续性决策涉及 AWS 区域选择和基础设施方面的能源效率选择，以及 Snowflake 侧的仓库整合、查询效率和数据生命周期管理。下表涵盖了可持续性领域，并提供了减少组合架构环境足迹的集成建议。

区域选择

• AWS 客户碳足迹工具、区域级碳强度
• Snowflake 区域可用性
• 为非延迟敏感的 Snowflake 工作负载选择与可持续性目标一致的 AWS 区域；对于灾难恢复，优先选择可再生能源比例高的次级区域

计算优化

• AWS 计算优化器、Amazon EC2 自动扩展
• 仓库自动挂起、无服务器任务
• 对开发和批量工作负载实施严格的自动挂起策略，以减少空闲计算；对间歇性工作负载优先使用无服务器功能

数据生命周期

• Amazon S3 智能分层、Amazon S3 Glacier 生命周期策略
• 时间旅行保留、临时表
• 将时间旅行保留与实际恢复需求对齐，以最小化存储足迹；用临时表替换完整数据副本，用于开发和测试

查询效率

• 批处理和实时处理最佳实践
• 查询分析、聚类键、物化视图、结果缓存
• 优化查询模式以减少总计算秒数；应用聚类键以避免全表扫描

使用镜像的三种方式

您可以在三种环境中访问该镜像，每种环境都针对不同的工作流程和团队偏好进行了设计。无论您的团队主要在 AWS 管理控制台工作，还是更喜欢在 IDE 中进行 AI 辅助的审查，或者在 Snowflake 中操作，都可以在不切换上下文的情况下运行完整的 Well-Architected 审查。

1. AWS Well-Architected Tool 控制台

该镜像可以直接在 AWS Well-Architected Tool 控制台中使用，用于对部署在 AWS 上的 Snowflake 工作负载进行结构化审查。结构化问卷涵盖了所有七个支柱，并包含针对 Snowflake 的问题，每个最佳实践都会被评估为高风险、中风险或未识别风险。审查会生成一个改进计划，包括优先级行动项、链接到 AWS 和 Snowflake 文档、里程碑跟踪以衡量随时间推移的进展，以及 PDF 或 JSON 格式的导出，用于向利益相关者报告和合规性证据。

开始操作步骤如下：

• 将 Snowflake AWS 自定义镜像 JSON 文件下载到本地计算机。

• 登录到 AWS Well-Architected Tool 控制台，并在导航窗格中选择“自定义镜像”。

• 选择“创建自定义镜像”，上传下载的 JSON 文件，然后选择“提交”。

2. Kiro

对于更喜欢 AI 辅助、对话式方法的团队，Snowflake 和 AWS WAF 镜像作为 Kiro Power 提供，这是 Kiro（AWS 的 AI 驱动 IDE）的一个集成功能。审查在 IDE 中以对话形式进行，每个支柱都有基于复选框的问题，因此无需导航到单独的控制台。发现结果使用红、黄、绿系统进行分类，以便快速识别风险。建议分为三个时间范围：立即（1–2 周）、下一步（30–60 天）和之后（90 天或更久）。输出包括用于主动健康检查和蓝图默认值的自动化映射，并支持客户就绪和内部交付计划格式。指导是上下文感知的，考虑到您的特定工作负载类型、合规要求和多区域需求。

• 将 Snowflake WAF Power 下载到本地计算机并解压缩。

• 在 Kiro 中，选择“打开文件夹”并选择解压后的文件夹。

• 在聊天中输入“运行 Snowflake 和 AWS WAF 审查”以开始。

3. Snowflake Cortex Code

除了使用 AWS Well-Architected Tool 和 Kiro 之外，您还可以选择 Cortex Code 编程助手路径。联合 Well-Architected 审查被打包为一个 Cortex Code 技能，您可以调用它来启动审查过程。调用时，该技能会以架构概述开始，并询问您希望如何继续。您可以与 AI 指导的建议进行交互式完整审查。Cortex Code 既可通过 CLI 使用，也可直接在 Snowsight 中使用，因此您可以选择最适合您工作流程的选项。

选项 A：Cortex Code CLI（本地终端）

• 将 AWS WAF 镜像的 Cortex Code 压缩文件下载到本地计算机上的某个位置并解压。

• 在计算机上打开终端窗口，并在 shell 提示符下输入 cortex skill add <path_to_the_unzipped_folder>。下图显示了一个示例。

• 在 shell 提示符下输入 cortex 以启动 Cortex Code CLI。

• 在 Cortex Code CLI 的聊天窗口中，输入 invoke the joint-waf-aws-lens skill 以开始。

选项 B：Snowsight 中的 Cortex Code（基于浏览器）

对于更倾向于留在 Snowflake 界面中的团队，Cortex Code 也可直接在 Snowsight 中使用，无需本地安装。

• 下载 AWS WAF 镜像的 Cortex Code 压缩文件并解压。

• 在 Snowsight 中，导航到“项目” > “工作区”，并打开（或创建）一个您希望运行此技能的工作区。

• 在 Snowsight 右下角选择 Cortex Code 图标，以打开助手面板。

• 在助手面板的聊天区域选择 + 添加上下文，然后选择上传技能文件夹（Upload Skill Folder(s)），接着选择已解压的技能文件夹。

• 在消息框中输入 run the joint-waf skill 并按下 Enter 键以开始审查。

架构支柱如何协同工作

使这个镜像独特的是，它将 AWS 基础设施指导直接整合到 Snowflake 特定的最佳实践中。

与为每个应用程序分别运行审查不同，该镜像可以帮助识别 Snowflake 架构风险，并同时展示相应的 AWS 补救路径，表明这两个层级需要如何对齐。

专为 Snowflake on AWS 而设计

该镜像反映了两个服务之间的集成专业知识：

• 统一的安全模型 – AWS 提供网络隔离、加密基础设施和身份联合。Snowflake 提供数据层保护，如动态掩码、行访问策略和 Tri-Secret Secure。该镜像展示了这些层级如何组合成一个统一的安全态势。

• FinOps 集成 – 成本支柱解决了在两个计费模型（AWS 基础设施成本和 Snowflake 消耗成本）之间优化支出的挑战。

• 运营一致性 – 运营卓越支柱连接了 AWS 原生的可观测性（Amazon CloudWatch、Amazon OpenSearch Service）和 Snowflake 原生的监控（Snowsight、Account Usage），使您能够构建跨越两个服务的连接仪表板和事件响应工作流程。

• 可持续性作为首要支柱 – 这是第一个将可持续性作为首要支柱的联合 ISV-AWS WAF 镜像。它将 AWS 区域选择策略与仓库整合、查询效率优化和数据生命周期管理相结合。

开始使用 Snowflake 和 AWS WAF 镜像

为了充分利用您第一次审查，从安全性和可靠性支柱开始，这些支柱整合了 AWS 和 Snowflake 的指导，能够揭示大多数生产工作负载中最具影响力的发现。使用改进计划输出来优先安排团队中的行动，并将结果导出为 PDF 或 JSON，用于利益相关者报告和合规性证据。

以下资源将帮助您深入了解本文中提到的 AWS 服务和 Snowflake 功能。

• AWS Well-Architected Tool

• AWS Well-Architected Framework

• Kiro 文档

• Snowflake Cortex Code

• Snowflake WAF

• Snowflake 中的 Tri-Secret Secure

• Snowflake Snowpipe

• Snowflake 零拷贝克隆

• Snowflake 工作负载身份联合

• Snowflake 敏感数据分类

下一步

这是 Snowflake 和 AWS WAF 镜像的首次发布，我们正在积极扩展其覆盖范围，提供更深入的 Snowflake on AWS 架构指导。

我们致力于实现 Snowflake on AWS 的云中良好架构。今天，您可以在 AWS Well-Architected Tool 或 Snowflake Cortex Code CLI 中开始您的首次审查，或者联系您的 AWS 账户团队或 Snowflake 账户团队，安排一次指导性研讨会。

关于作者

'\"