Wa Guardrails

Well-Architected Guardrails

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).

Step 1: Gather context

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.

Step 2: Discovery — what to enforce

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).

Step 3: Select preventive vs. detective for each control

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.

Step 4: Generate the controls

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:

# 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:

// 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):

# guardrails/reliability.guard
# 🛡️ Preventive — blocks RDS instances without Multi-AZ + deletion protection
AWS::RDS::DBInstance {
  Properties { MultiAZ == true  DeletionProtection == true }
}