wa-guardrails

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Well-Architected Guardrails

Well-Architected 护栏

This skill generates preventive and detective controls that keep a workload Well-Architected over time. Unlike the assessment skills (which find gaps) or remediation (which fixes a specific finding once), guardrails codify best practices so non-compliant changes are blocked or flagged automatically — in CI, at deploy time, and continuously in the account.

What you'll produce: ready-to-commit control files (Config rules, SCPs, CI policy checks, alarms), each tied to the WA Question/Best Practice ID it enforces, with a note on whether the control is preventive (blocks the bad change) or detective (flags it after the fact).

本技能可生成预防性和检测性控制措施，确保工作负载长期符合Well-Architected标准。与评估类技能（仅发现差距）或修复类技能（仅一次性修复特定问题）不同，护栏会将最佳实践编码为自动化规则，在CI流程、部署阶段以及账户内持续运行，自动阻止或标记不合规的变更。

输出内容： 可直接提交的控制文件（Config规则、SCP、CI策略检查、告警），每个文件均关联其强制执行的WA问题/最佳实践ID，并标注该控制措施属于预防性（阻止不良变更）还是检测性（事后标记问题）。

Step 1: Gather context

步骤1：收集上下文

Ask the user (skip any already provided or inferable from the codebase):

I can generate guardrails to keep your workload Well-Architected. Let me know:
Workload name and code packages/directories (IaC, CI/CD configs)

IaC dialect: CDK (which language), CloudFormation, Terraform, SAM, or mixed
Source of controls: a prior
/aws-well-architected-framework-review
or assessment output, specific concerns, or "scan and propose"
Enforcement points available: CI pipeline (which one), AWS Organizations/SCPs, AWS Config, account-level admin — so controls target what you can actually deploy

Pillars to prioritize (optional; default: Security and Reliability)

If you are in a codebase, proceed directly and infer the IaC dialect and CI system from the files present.

询问用户（跳过已提供或可从代码库推断的信息）：

我可以生成护栏来确保您的工作负载符合Well-Architected标准。请告知：
工作负载名称及代码包/目录（IaC、CI/CD配置文件）

IaC方言：CDK（使用哪种语言）、CloudFormation、Terraform、SAM，或混合使用
控制措施来源：之前的
/aws-well-architected-framework-review
评估结果、特定关注点，或“扫描并建议”
可用的执行点：CI流水线（具体是哪一种）、AWS Organizations/SCP、AWS Config、账户级管理员权限——确保控制措施适配您实际可部署的环境

优先关注的支柱（可选；默认：安全与可靠性）

若处于代码库环境中，可直接从现有文件推断IaC方言和CI系统，无需询问。

Step 2: Discovery — what to enforce

步骤2：发现阶段——确定需强制执行的内容

Determine the controls to generate from one of two inputs:

Path A — From an assessment (preferred): parse the prior review for findings, their pillar, severity, evidence (file:line), and the Best Practice IDs cited. Each High/Critical finding becomes a candidate guardrail so the same gap cannot recur.

Path B — Standalone scan: analyze the IaC and identify the control-worthy configurations actually in use — storage encryption, public access, IAM scope, multi-AZ, backups, logging, TLS, tagging. Map each to the WA Best Practice it relates to.

Produce a control candidate list: for each, record the pillar, the WA Question/BP ID, the resource type it applies to, the current state (compliant / non-compliant / absent), and the enforcement point that fits (CI check, Config rule, SCP, alarm).

从以下两种输入之一确定要生成的控制措施：

路径A——基于评估结果（推荐）： 解析之前的审查结果，提取问题、所属支柱、严重程度、证据（文件:行号）以及引用的最佳实践ID。每个高/严重级别的问题都会成为护栏候选，避免相同问题再次出现。

路径B——独立扫描： 分析IaC，识别实际使用中需要控制的配置——存储加密、公共访问、IAM权限范围、多AZ部署、备份、日志记录、TLS、标签等。将每个配置映射到对应的WA最佳实践。

生成控制候选列表：为每个候选记录所属支柱、WA问题/BP ID、适用的资源类型、当前状态（合规/不合规/缺失），以及适配的执行点（CI检查、Config规则、SCP、告警）。

Step 3: Select preventive vs. detective for each control

步骤3：为每个控制措施选择预防性或检测性类型

For every candidate, choose the strongest control the user's enforcement points allow. Prefer preventive (stops the bad change before it ships) over detective (catches it afterward). Use this decision guidance:

Can the misconfiguration be caught in IaC before deploy? → CI policy check (CDK Aspect,
```
cfn-guard
```
/
```
cfn-lint
```
, Terraform OPA/Sentinel). Strongest and cheapest.
Must it be blocked org-wide regardless of who deploys? → SCP or permission boundary.
Is it only observable on the live resource (e.g. drift, runtime state)? → AWS Config rule (detective; add auto-remediation only if the user confirms).
Is it a continuous reliability/cost/performance signal? → CloudWatch metric + alarm.

If a control cannot be enforced with the available points, say so explicitly rather than emitting a control that won't run.

针对每个候选，选择用户可用执行点支持的最强控制措施。优先选择预防性措施（在变更发布前阻止不良操作）而非检测性措施（事后发现问题）。决策指导如下：

配置错误能否在部署前的IaC阶段被发现？→ CI策略检查（CDK Aspect、
```
cfn-guard
```
/
```
cfn-lint
```
、Terraform OPA/Sentinel）。这是最强且成本最低的方式。
是否需要在组织范围内阻止该错误，无论部署者是谁？→ SCP或权限边界。
该问题仅能在实时资源上观测到（如配置漂移、运行时状态）？→ AWS Config规则（检测性；仅在用户确认后添加自动修复功能）。
该问题属于持续的可靠性/成本/性能信号？→ CloudWatch指标+告警。

若某个控制措施无法通过可用执行点实施，请明确告知，而非生成无法运行的控制措施。

Step 4: Generate the controls

步骤4：生成控制措施

Generate every selected control as ready-to-commit code in the workload's existing dialect and conventions. Each control MUST:

Cite the WA Question/BP ID it enforces (e.g.
```
SEC 8
```
,
```
REL 9
```
)
Be labeled 🛡️ Preventive or 🔍 Detective
Include a one-line statement of what it blocks/flags and why it matters

Cover, as applicable to the workload:

Security (SEC) — examples:

s3-bucket-server-side-encryption-enabled

s3-bucket-public-read-prohibited

iam-policy-no-statements-with-admin-access

(Config); SCP denying creation of unencrypted resources or disabling CloudTrail; a CDK Aspect failing synth on a security group open to

0.0.0.0/0

on non-web ports.

Reliability (REL) —

rds-multi-az-support

dynamodb-pitr-enabled

db-instance-backup-enabled

(Config); a

cfn-guard

rule requiring

DeletionProtection

on stateful resources; an alarm on DLQ depth.

Operational Excellence (OPS) — a CI check requiring tags (owner, cost-center, environment); a Config rule for required CloudWatch log retention; an SCP preventing manual changes outside IaC.

Cost (COST) — a CI check flagging instance types or capacity modes outside an approved list; a budget/anomaly alarm.

Performance / Sustainability (PERF/SUS) — a CI check preferring Graviton/managed services where applicable.

Provide each control's snippet in a fenced code block with the target filename, so the user can commit it directly. Match the workload's dialect — examples of the three most common forms:

Detective — AWS Config managed rule (SEC 8, encryption at rest), CloudFormation:

yaml

undefined

按照工作负载现有的方言和约定，生成所有选定的控制措施代码，确保可直接提交。每个控制措施必须：

关联其强制执行的WA问题/BP ID（例如
```
SEC 8
```
、
```
REL 9
```
）
标注 🛡️ 预防性或 🔍 检测性
包含一行说明，解释其阻止/标记的内容及重要性

覆盖与工作负载相关的以下支柱：

安全（SEC）——示例：

s3-bucket-server-side-encryption-enabled

、

s3-bucket-public-read-prohibited

、

iam-policy-no-statements-with-admin-access

（Config规则）；禁止创建未加密资源或禁用CloudTrail的SCP；在安全组对非Web端口开放

0.0.0.0/0

时，导致

cdk synth

失败的CDK Aspect。

可靠性（REL）——

rds-multi-az-support

、

dynamodb-pitr-enabled

、

db-instance-backup-enabled

（Config规则）；要求有状态资源启用

DeletionProtection

的

cfn-guard

规则；死信队列（DLQ）深度告警。

卓越运营（OPS）——要求添加标签（所有者、成本中心、环境）的CI检查；要求CloudWatch日志保留期的Config规则；禁止在IaC之外进行手动变更的SCP。

成本（COST）——标记未在批准列表中的实例类型或容量模式的CI检查；预算/异常告警。

性能/可持续性（PERF/SUS）——优先选择Graviton/托管服务的CI检查。

为每个控制措施提供带目标文件名的代码块，方便用户直接提交。匹配工作负载的方言——以下是三种最常见形式的示例：

检测性——AWS Config托管规则（SEC 8，静态加密），CloudFormation：

yaml

undefined

guardrails/config-rules.yaml

Resources: S3EncryptionEnabled: # 🔍 Detective — flags any S3 bucket without SSE Type: AWS::Config::ConfigRule Properties: ConfigRuleName: s3-bucket-server-side-encryption-enabled Source: { Owner: AWS, SourceIdentifier: S3_BUCKET_SERVER_SIDE_ENCRYPTION_ENABLED }


**Preventive — CDK Aspect (SEC 5, no open security groups), TypeScript:**

```typescript
// guardrails/no-open-sg.aspect.ts
import { IAspect, Annotations } from "aws-cdk-lib";
import { CfnSecurityGroupIngress } from "aws-cdk-lib/aws-ec2";
import { IConstruct } from "constructs";

// 🛡️ Preventive — fails `cdk synth` on 0.0.0.0/0 ingress to non-web ports
export class NoOpenIngress implements IAspect {
  visit(node: IConstruct): void {
    if (node instanceof CfnSecurityGroupIngress &&
        node.cidrIp === "0.0.0.0/0" && ![80, 443].includes(Number(node.fromPort))) {
      Annotations.of(node).addError(`SEC 5: security group open to 0.0.0.0/0 on port ${node.fromPort}`);
    }
  }
}

Preventive — cfn-guard rule (REL 9, stateful resources need deletion protection):

undefined


**预防性——CDK Aspect（SEC 5，禁止开放安全组），TypeScript：**

```typescript
// guardrails/no-open-sg.aspect.ts
import { IAspect, Annotations } from "aws-cdk-lib";
import { CfnSecurityGroupIngress } from "aws-cdk-lib/aws-ec2";
import { IConstruct } from "constructs";

// 🛡️ Preventive — fails `cdk synth` on 0.0.0.0/0 ingress to non-web ports
export class NoOpenIngress implements IAspect {
  visit(node: IConstruct): void {
    if (node instanceof CfnSecurityGroupIngress &&
        node.cidrIp === "0.0.0.0/0" && ![80, 443].includes(Number(node.fromPort))) {
      Annotations.of(node).addError(`SEC 5: security group open to 0.0.0.0/0 on port ${node.fromPort}`);
    }
  }
}

预防性——cfn-guard规则（REL 9，有状态资源需启用删除保护）：

undefined

guardrails/reliability.guard

🛡️ Preventive — blocks RDS instances without Multi-AZ + deletion protection

AWS::RDS::DBInstance { Properties { MultiAZ == true DeletionProtection == true } }

undefined

AWS::RDS::DBInstance { Properties { MultiAZ == true && DeletionProtection == true } }

undefined

Step 5: Produce the guardrails plan

步骤5：生成护栏计划

Output a structured deliverable:

markdown

undefined

输出结构化交付成果：

markdown

undefined

Well-Architected Guardrails: {Workload Name}

Summary

摘要

IaC dialect: {CDK/CloudFormation/Terraform/SAM}
Enforcement points used: {CI / Config / SCP / alarms}
Source: {prior review / standalone scan}
Controls generated: {N} ({P} preventive, {D} detective) across {pillars}

IaC方言: {CDK/CloudFormation/Terraform/SAM}
使用的执行点: {CI / Config / SCP / alarms}
来源: {之前的审查结果 / 独立扫描}
生成的控制措施: {N} 项（{P} 项预防性，{D} 项检测性），覆盖{pillars}支柱

Controls by pillar

按支柱分类的控制措施

{Pillar} — {WA Question/BP ID}

Control: {name} | 🛡️ Preventive / 🔍 Detective | Enforcement: {CI / Config / SCP / alarm}
Blocks/flags: {what, and why it matters}
File:
```
{path}
```
```
{ready-to-commit snippet}
```
Coverage gap (if any): {what this control does NOT catch}

控制措施: {名称} | 🛡️ 预防性 / 🔍 检测性 | 执行方式: {CI / Config / SCP / alarm}
阻止/标记内容: {具体内容及重要性}
文件路径:
```
{path}
```
```
{可直接提交的代码片段}
```
覆盖缺口（如有）: {该控制措施未覆盖的内容}

Rollout plan

部署计划

Order	Control	Enforcement	Risk of false-positive	Notes
{Start in warn/log mode for preventive CI checks and SCPs, then promote to block once clean.}

顺序	控制措施	执行方式	误报风险	说明
{预防性CI检查和SCP先以警告/日志模式启动，待无问题后再升级为阻止模式。}

Verification

验证方式

{How to confirm each control works — e.g. attempt a known-bad change in a branch and confirm CI fails; check Config rule compliance status.}

{如何确认每个控制措施生效——例如，在分支中尝试已知的不良变更，确认CI失败；检查Config规则合规状态。}

Not covered

未覆盖内容

{Controls the available enforcement points cannot implement, and what would be needed.}

undefined

{可用执行点无法实现的控制措施，以及所需的条件。}

undefined

Step 6: Offer a governance steering doc

步骤6：提供治理指导文档

Beyond machine-enforced controls, offer to capture the same standards as a human- and agent-readable governance doc — the prose counterpart to the guardrails. This is useful for the standards a control can't fully express (design conventions, review expectations) and for teams that want an always-on policy their AI coding agent will follow.

Generate it on request as a steering file the agent loads automatically (e.g.

.kiro/steering/

CLAUDE.md

.cursor/rules/

), structured as:

markdown

undefined

除了机器强制执行的控制措施外，还可提供人类和Agent可读的治理指导文档——作为护栏的文字补充。这适用于控制措施无法完全表达的标准（设计约定、审查要求），以及希望AI编码Agent遵循始终启用的策略的团队。

根据请求生成指导文件，Agent会自动加载（例如

.kiro/steering/

、

CLAUDE.md

、

.cursor/rules/

），结构如下：

markdown

undefined

{Workload} — Well-Architected Guardrails (Governance)

Enforced automatically

自动强制执行的规则

{One line per machine control, linking the rule file and its WA BP ID — so readers know what is already gated in CI/Config.}

{每条机器控制措施对应一行，关联规则文件和WA BP ID——让读者了解CI/Config中已管控的内容。}

Conventions to follow (not auto-enforced)

需遵循的约定（非自动强制执行）

{Pillar} — {convention}, because {WA BP ID rationale}. {How a reviewer/agent checks it.}

{Pillar} — {约定内容}，依据{WA BP ID}的原则。{审查者/Agent的检查方式。}

When proposing or reviewing changes to this workload

提出或审查本工作负载变更时的要求

{Standing instruction, e.g. "new data stores MUST set encryption + backups before merge (SEC 8 / REL 9)"}


Keep each statement tied to a WA Question/BP ID, and keep the doc short enough to live in always-on context without bloat.

{常规指令，例如“新数据存储在合并前必须启用加密+备份（SEC 8 / REL 9）”}


每条陈述均需关联WA问题/BP ID，文档需简洁，适合作为始终启用的上下文内容，避免冗余。

Step 7: Offer follow-up

步骤7：提供后续服务

Would you like me to:
Generate the CI workflow wiring (GitHub Actions / CodePipeline step) to run the policy checks?
Produce a governance steering doc (
CLAUDE.md
/
.cursor/rules/
/
.kiro/steering/
) capturing these standards for your AI agent?
Add auto-remediation to a detective Config rule (with safety review)?

Fix the existing violations these guardrails would block (remediate the current code)?

Tighten a control from warn mode to block mode?

您是否需要我：
生成CI工作流配置（GitHub Actions / CodePipeline步骤）以运行策略检查？
生成治理指导文档（
CLAUDE.md
/
.cursor/rules/
/
.kiro/steering/
），为您的AI Agent记录这些标准？
为检测性Config规则添加自动修复功能（需安全审查）？

修复现有违反这些护栏规则的问题（修复当前代码）？

将控制措施从警告模式升级为阻止模式？

Calibration Guidance

校准指南

Prefer preventive controls (catch in CI/IaC) over detective — they're cheaper and stop the problem before it ships; only fall back to detective when the issue is only visible on the live resource.
Never emit a control for an enforcement point the user doesn't have — say it's not enforceable and what's needed instead.
Roll out preventive controls in warn/log mode first. Recommending a hard
```
block
```
or
```
Deny
```
SCP on day one risks breaking existing pipelines — flag this and stage it.
Auto-remediation is destructive: only generate it when the user explicitly asks, and include a safety/rollback note.
Tie every control to a WA Question/BP ID so the builder can trace the rationale — a guardrail without a "why" gets disabled the first time it's inconvenient.
Don't over-generate: a focused set of high-value controls that the team will keep beats 50 noisy rules they'll mute.
Respect the workload's existing dialect and conventions — emit CDK Aspects for a CDK app,
```
cfn-guard
```
for CloudFormation, OPA/Sentinel for Terraform; don't mix paradigms.
The governance steering doc complements controls, it doesn't replace them — prefer a machine-enforced control whenever one exists, and use the doc for what code can't express. Keep it concise enough for always-on context.

优先选择预防性控制措施（在CI/IaC阶段发现问题）而非检测性措施——成本更低，且能在问题发布前阻止；仅当问题仅能在实时资源上观测到时，才使用检测性措施。
切勿为用户不具备的执行点生成控制措施——应告知无法实施，并说明所需条件。
预防性控制措施先以警告/日志模式部署。第一天就建议硬“阻止”或“拒绝”的SCP可能会破坏现有流水线——需标注此风险并分阶段部署。
自动修复具有破坏性：仅在用户明确要求时生成，并包含安全/回滚说明。
每条控制措施均需关联WA问题/BP ID，以便开发人员追溯依据——没有“原因”的护栏会在首次造成不便时被禁用。
避免过度生成：团队会持续维护的少量高价值控制措施，胜过50条会被忽略的嘈杂规则。
遵循工作负载现有的方言和约定——为CDK应用生成CDK Aspects，为CloudFormation生成
```
cfn-guard
```
规则，为Terraform生成OPA/Sentinel规则；不要混合范式。
治理指导文档是控制措施的补充，而非替代——只要存在机器可强制执行的控制措施，优先使用；文档用于代码无法表达的内容。保持简洁，适合作为始终启用的上下文内容。