Use this file to discover all available pages before exploring further.
The wa-guardrails skill teaches your AI coding agent to generate ready-to-commit preventive and detective controls that keep a workload Well-Architected over time. Where assessment skills find gaps and remediation fixes them once, guardrails codify best practices so non-compliant configurations are blocked or flagged automatically — in CI/CD pipelines, at deploy time, and continuously across the account.
CDK Aspects that fail cdk synth, cfn-guard rules for CloudFormation, and OPA/Sentinel policies for Terraform — catching misconfigurations before they ever deploy. Strongest and cheapest enforcement point.
AWS Config Rules
Managed and custom Config rules for continuous compliance checking of live resources — detecting drift, unencrypted buckets, disabled backups, and missing Multi-AZ configurations.
Service Control Policies
SCPs that prevent non-compliant resource creation org-wide — blocking public S3 bucket creation, disabling of CloudTrail, or unencrypted RDS instance launches regardless of who deploys.
CloudWatch Alarms
Individual and composite alarms for operational guardrails — DLQ depth, error rates, latency thresholds, and cost anomalies — each tied to the WA Best Practice ID it enforces.
The skill always selects the strongest control your enforcement points allow, preferring preventive over detective:
1
CI/CD policy check (strongest — preventive)
Can the misconfiguration be caught in IaC before deploy? If yes, the skill generates a CDK Aspect, cfn-guard rule, or Terraform OPA policy. This stops the bad configuration from ever reaching AWS.
2
SCP or permission boundary (preventive, org-wide)
Must the control apply across the entire AWS Organization regardless of who deploys? SCPs and permission boundaries are generated for hard-line controls like “never allow public S3 buckets” or “never disable CloudTrail.”
3
AWS Config rule (detective)
Is the issue only visible on a live resource — drift, runtime state, or configurations that can’t be validated in IaC? Config rules are generated as detective controls, with auto-remediation offered only on explicit request.
4
CloudWatch alarm (detective, operational)
Is the issue a continuous reliability, cost, or performance signal? Alarms and composite alarms are generated for operational guardrails.
The skill never generates a control for an enforcement point you don’t have. If a control can’t be enforced with your available points, it states this explicitly and explains what would be needed.
Config rules: s3-bucket-server-side-encryption-enabled, s3-bucket-public-read-prohibited, iam-policy-no-statements-with-admin-access, cloudtrail-enabledSCPs: Deny creation of unencrypted S3 buckets; deny disabling of CloudTrail; deny creation of IAM users with console accessCDK Aspects: Fail synth on security groups open to 0.0.0.0/0 on non-web ports; fail synth on KMS keys without key rotation enabledWA questions covered: SEC 1, SEC 2, SEC 5, SEC 7, SEC 8
CI/CD checks: Graviton preference check (warn on x86 Lambda where arm64 applies); managed service preference (flag self-managed Redis/Kafka)WA questions covered: PERF 1, SUS 5
# Well-Architected Guardrails: payments-service## Summary- IaC dialect: CDK TypeScript- Enforcement points used: CDK Aspects (CI), AWS Config, CloudWatch Alarms- Source: wa-review output (2025-06-01)- Controls generated: 12 (7 preventive, 5 detective) across Security, Reliability, Operational Excellence## Controls by pillar### Security — SEC 8 (Encryption at rest)- Control: S3 server-side encryption | 🔍 Detective | Enforcement: AWS Config- Blocks/flags: S3 buckets created without SSE — encryption protects against unauthorized access to raw storage and satisfies common compliance requirements- File: `guardrails/config-rules.yaml`- Coverage gap: Does not enforce specific KMS key — add CMK Aspect for stricter enforcement### Security — SEC 5 (Network protection)- Control: No open security groups | 🛡️ Preventive | Enforcement: CDK Aspect (CI)- Blocks/flags: Security groups allowing 0.0.0.0/0 ingress on non-web ports — overly permissive ingress is the most common lateral movement enabler- File: `guardrails/no-open-sg.aspect.ts`### Reliability — REL 9 (Data backup)- Control: RDS Multi-AZ + deletion protection | 🛡️ Preventive | Enforcement: cfn-guard (CI)- Blocks/flags: RDS instances without Multi-AZ or DeletionProtection — prevents accidental single-AZ database deployments that create SPOFs- File: `guardrails/reliability.guard`## Rollout plan| Order | Control | Enforcement | False-positive risk | Notes ||-------|---------------------------|-------------|---------------------|--------------------------------|| 1 | S3 encryption Config rule | Config | Low | Warn mode for 1 week first || 2 | No open SG Aspect | CDK CI | Medium | Audit existing SGs before block|| 3 | RDS cfn-guard rule | CI | Low | Test on dev stack first || 4 | SCP: no public S3 | Organizations| Low | Apply to non-prod OU first |## Verification- S3 encryption rule: create an unencrypted bucket in a test account — Config should flag within 15 minutes and mark it NON_COMPLIANT- No open SG Aspect: add an unrestricted ingress rule to a dev stack — `cdk synth` must fail with SEC 5 error message- cfn-guard rule: run `cfn-guard validate -r guardrails/reliability.guard -d test/rds-no-multiaz.json` — must return FAIL
After generating machine-enforced controls, the skill offers to produce a companion governance document — a human- and agent-readable steering file that covers standards no control can fully express.
# payments-service — Well-Architected Guardrails (Governance)## Enforced automatically- SEC 5: `guardrails/no-open-sg.aspect.ts` — blocks 0.0.0.0/0 ingress at synth time- SEC 8: `guardrails/config-rules.yaml` → S3EncryptionEnabled — flags unencrypted buckets- REL 9: `guardrails/reliability.guard` — blocks RDS without Multi-AZ and deletion protection## Conventions to follow (not auto-enforced)- Security — New IAM roles must follow least-privilege; request only actions needed for the specific task (SEC 2). Reviewed in PRs by a security-aware team member.- Reliability — Every new stateful resource must have a defined recovery objective documented in its stack file (REL 9). Reviewer checks for backup retention and PITR.- Cost — New Lambda functions should use arm64 architecture unless a specific x86 dependency is documented in the PR (SUS 5 / COST 6).## When proposing or reviewing changes to this workload- New data stores MUST have encryption + backups before merge (SEC 8 / REL 9)- New network resources MUST NOT open 0.0.0.0/0 on non-web ports (SEC 5) — enforced by Aspect- Any new public endpoint MUST have a WAF rule set associated (SEC 6)
This governance doc can be saved as a steering file for Kiro (.kiro/steering/), Claude Code (CLAUDE.md), Cursor (.cursor/rules/), or any supported tool — giving your AI coding agent always-on awareness of the standards.
Always roll out preventive controls in warn/log mode first. Applying a hard Deny SCP or a blocking CDK Aspect directly to existing pipelines risks breaking deployments. The skill flags this and stages rollout accordingly.
Auto-remediation on Config rules is destructive — it modifies live resources automatically. The skill only generates auto-remediation code when you explicitly request it, and always includes a safety review and rollback note.
Evaluated using an automated LLM-as-judge framework with paired comparison (same prompt, with and without skill context) using Claude Opus 4.8.
Baseline
With skill
Delta
Score
76%
99%
+23%
A bare agent can describe what guardrails should exist; the skill generates commit-ready code in your workload’s actual dialect, tied to WA BP IDs, with rollout staging guidance — the gap that drives the +23% improvement.
