Snowflake + AWS Well-Architected 自定义 Lens：一次审查覆盖两层架构

预计阅读时间：9 分钟

过去在 AWS 上跑 Snowflake 的团队做架构审查，要翻两份文档——AWS Well-Architected Framework 的六大支柱和 Snowflake 自己的最佳实践指南，再人工拼凑出"这两个东西搭在一起到底该怎么配"。新发布的 Snowflake and AWS Custom Lens 把两套建议压进一次审查流程，给出的推荐直接反映 AWS 与 Snowflake 在生产环境中的组合方式，不再靠你自己脑补交叉点。

六个支柱里加了什么

Custom Lens 在 AWS Well-Architected 原有的六个支柱（Operational Excellence、Security、Reliability、Performance Efficiency、Cost Optimization、Sustainability）下，针对每个支柱插入了 Snowflake 侧的问题和决策点。几个值得注意的交叉场景：

Security——Snowflake 的 Network Policy、Row-Level Security 与 AWS VPC、IAM Policy 如何对齐；数据加密在 S3 端和 Snowflake 端分别由谁负责。
Reliability——Snowflake Virtual Warehouse 的 auto-suspend/auto-resume 策略与 AWS 多可用区部署的协调；Snowflake 内部故障转移与 AWS 区域级灾备的关系。
Cost Optimization——Warehouse 大小选择与 AWS 数据传输费用的联动；Snowflake Storage 计费模型与 S3 lifecycle policy 的取舍。
Performance Efficiency——Snowflake缓存机制与 AWS S3 Intelligent-Tiering 的交互；查询结果缓存命中率的监控如何接入 CloudWatch。

每个问题都附带"双栈"推荐：比如在 Security 支柱下，Lens 会同时提醒你检查 AWS IAM Role 的 trust policy 和 Snowflake 的 OAuth integration 配置是否一致，而不是只看一侧。

三种入口，选哪个

Lens 提供了三个访问方式，适配不同工作习惯：

入口	适合场景	特点
AWS Management Console	团队首次审查、需要可视化问卷	直接嵌入 Well-Architected Tool，逐题勾选，自动生成报告
Kiro	开发者在 IDE 内做日常自检	Kiro 是 AWS 新推出的 AI 驱动 IDE，Lens 作为 spec 文件可直接在项目内引用
Snowflake Cortex Code	Snowflake 侧开发者、数据工程师	在 Snowflake 的 AI coding 环境中调用，侧重数据层审查

Console 入口最直观，适合第一次跑完整审查；Kiro 和 Cortex Code 更适合把 Lens 嵌入日常开发流程，做持续自检而非一次性评估。

实操：用 AWS CLI 跑一次 Custom Lens 审查

下面用 AWS CLI 完成从加载 Lens 到创建审查的全流程。前提是你已有 AWS 账号权限和 Snowflake 工作负载。

1. 加载 Custom Lens 到你的 AWS 账号

Custom Lens 以 JSON 文件发布，需要先上传到 Well-Architected Tool：

# 下载 Lens JSON（发布页会提供 S3 链接，这里用占位路径）
aws s3 cp s3://snowflake-aws-waf-lens/SnowflakeAWSLens.json ./SnowflakeAWSLens.json

# 创建 Custom Lens
aws wellarchitected create-lens-version \
  --lens-alias snowflake-aws-custom-lens \
  --lens-version 1.0 \
  --json-file ./SnowflakeAWSLens.json \
  --region us-east-1

Lens alias 在首次创建时由 AWS 分配，后续操作用 alias 引用。如果 Lens 已在 AWS 官方 Lens 库中发布，你可以直接调用 list-lenses 确认可用性，跳过上传步骤：

aws wellarchitected list-lenses \
  --query "LensSummaries[?LensAlias=='snowflake-aws-custom-lens']" \
  --region us-east-1

2. 创建 Workload 并关联 Lens

# 定义你的工作负载
aws wellarchitected create-workload \
  --workload-name "snowflake-production-analytics" \
  --description "Production analytics pipeline on Snowflake + AWS" \
  --environment PRODUCTION \
  --regions us-east-1 \
  --pillar-list "Operational Excellence,Security,Reliability,Performance Efficiency,Cost Optimization,Sustainability" \
  --region us-east-1

# 记录返回的 WorkloadId
WORKLOAD_ID=$(aws wellarchitected list-workloads \
  --query "WorkloadSummaries[?WorkloadName=='snowflake-production-analytics'].WorkloadId" \
  --output text \
  --region us-east-1)

# 将 Custom Lens 关联到 Workload
aws wellarchitected associate-lens \
  --workload-id "$WORKLOAD_ID" \
  --lens-alias snowflake-aws-custom-lens \
  --region us-east-1

3. 开始审查——回答 Lens 中的问题

审查以问卷形式推进，每个问题有多个选项（从最佳到最差排列）。CLI 下用 update-answer 逐题提交：

# 示例：回答 Security 支柱下关于 Network Policy 的问题
# QuestionId 和 ChoiceId 需从 Lens JSON 中查阅，以下为示意值
aws wellarchitected update-answer \
  --workload-id "$WORKLOAD_ID" \
  --lens-alias snowflake-aws-custom-lens \
  --question-id "SEC_Q01_network_policy_alignment" \
  --selected-choices "SEC_Q01_choice_a_both_aligned" \
  --region us-east-1

实际操作中，逐题 CLI 效率不高。更实用的做法是：

首次完整审查用 Console 问卷界面，可视化勾选，一键生成报告。
日常增量检查用 Kiro 或 Cortex Code，在代码变更时自动触发相关问题的复查。

4. 导出审查报告

# 获取 Lens 审查概览（风险分布）
aws wellarchitected get-lens-review \
  --workload-id "$WORKLOAD_ID" \
  --lens-alias snowflake-aws-custom-lens \
  --region us-east-1 \
  --query "LensReview.PillarReviewSummaries"

输出会按支柱列出风险等级（High / Medium / Low / No Risk），以及每个支柱的改进项数量。

在 Kiro 中嵌入 Lens Spec

如果你用 Kiro 做 IDE 内自检，Lens 会以 spec 文件形式存在于项目目录：

# .kiro/specs/well-architected-snowflake-aws.md
# Kiro 会读取此文件并在代码变更时自动对照检查

spec:
  name: snowflake-aws-well-architected
  version: 1.0
  pillars:
    - security:
        checks:
          - iam_role_trust_policy_matches_snowflake_oauth
          - s3_encryption_aligned_with_snowflake_stage
          - network_policy_blocks_public_access
    - cost_optimization:
        checks:
          - warehouse_auto_suspend_enabled
          - s3_lifecycle_policy_not_conflicting_with_snowflake_retention

Kiro 在你修改 IAM 配置或 Snowflake Stage 定义时，会自动提醒是否满足 Lens 中的检查项。

什么时候该用、什么时候不必

适合用的场景：

你的架构确实是 AWS + Snowflake 双栈，数据在 S3 与 Snowflake 之间有双向流动。
团队对"哪一侧该管什么"存在模糊地带——比如加密责任、网络边界、计费归属。
需要向合规团队出具一份覆盖两层的架构审查报告。

不必强行用的场景：

Snowflake 只是纯消费端（数据全在 Snowflake 内部，AWS 只做客户端接入），交叉问题极少。
你已经有成熟的内部审查清单，Lens 的建议与你的实践高度重叠——加载它只是多了一步操作。
团队没人用 Kiro 或 Cortex Code，且 Console 问卷的频率很低（一年一次），手动对照两份文档的成本可接受。

几个务实提醒：

Lens 版本会随 Snowflake 和 AWS 功能更新迭代，跑完第一次审查后，关注 Lens 的 changelog——新问题可能对应你还没遇到但即将遇到的风险。
审查报告中的"High Risk"项不要全堆给一个季度解决，按数据流向的敏感度排序：先修 Security 和 Reliability 的 High，再处理 Cost Optimization。
如果你的 Snowflake 账号跨多个 AWS 区域，审查时每个区域要单独评估 Network Policy 和数据传输路径，Lens 的问卷在 Region 层面有区分。

这个 Custom Lens 的核心价值不是"多了一份文档"，而是把两套原本独立的知识体系在交叉点上做了对齐。对于已经在 AWS 上跑 Snowflake 的团队，第一次审查大概率会暴露至少两三个你之前没意识到归属模糊的配置项。跑一次，花不了两小时，但可能省下后续排障的几天。