aws-waf-sustainability-skill

When to Use

Apply this skill any time an agent designs, reviews, or right-sizes AWS resources where energy, carbon impact, or wasted capacity is a stake. In practice that is essentially every solution-architect or implementation pass that touches compute, storage, or data movement.

Trigger conditions:

• The orchestrator's solution-architect specialist is producing design.md and must honor the Well-Architected Sustainability pillar alongside the other pillars.
• A component contract under .claude/specs/<feature>/contracts/<name>.md is being authored or revised; the pillar must inform the choice of compute family, storage tier, and region.
• A cost-pillar review is concluding; sustainability concerns frequently overlap (right-sizing, scale-to-zero, Graviton) and must be reconciled, not duplicated.
• The user explicitly asks for a "green" architecture, a carbon report, or low-environmental-impact options.
• A region-selection decision is on the table — sustainability is one of three inputs (with cost and latency).

Do not apply this skill to non-AWS workloads, to cost-only optimisations that have no compute or storage impact (e.g. a Reserved-Instance commitment review), or to retrospective carbon-footprint reporting (that is a separate quarterly workflow, not a design-time skill).

Procedure

1. Pick the lowest-carbon viable region. Consult references/region-carbon-tiers.md. Tier-1 regions (≥95% renewable energy per AWS-published figures) are eligible by default. If data-residency or latency constraints exclude tier-1, pick the lowest-carbon region in the eligible set and label the deviation in the contract's sustainability: block with the specific constraint that drove the choice.
2. Default to Graviton. Choose arm64 instance families (t4g, m7g, c7g, r7g, m8g, c8g) unless the workload provably requires x86_64. Every non-Graviton choice must carry a requires-x86: <reason> rationale in the contract — common legitimate reasons are documented in references/graviton-eligibility.md.
3. Right-size before scaling. Issue a cw MCP query for Compute Optimizer recommendations on existing workloads, or use the workload's measured peak from load tests. Avoid the "round up to be safe" antipattern; the contract must record the actual measured peak and the percentile chosen (e.g. "p99.9 over 14 days").
4. Default to managed/serverless. Lambda, Fargate, App Runner, EventBridge, SQS, SNS, DynamoDB on-demand — these scale to zero and amortize cooling/idle across thousands of customers. A self-hosted EC2 / ECS-on-EC2 / RDS choice must justify in the contract why a managed equivalent does not fit (latency floor, license model, library constraint).
5. Tier storage by access pattern. Default S3 lifecycle: Standard → Standard-IA after 30 days → Glacier Instant Retrieval after 90 → Glacier Deep Archive after 180, unless retrieval-time SLOs forbid. Prefer EBS gp3 over gp2 (gp3 charges separately for IOPS and throughput, eliminating idle waste). Apply CloudWatch Logs retention; never leave the default of "never expire".
6. Cap data transfer. Co-locate compute and data in the same AZ where the workload's availability profile permits; use VPC endpoints for AWS-API traffic; avoid cross-region replication unless DR or compliance demands it. Cache at the edge (CloudFront) instead of repeatedly serving from origin. Each cross-AZ or cross-region data path must be enumerated in the sustainability: block.
7. Schedule for idle. Non-prod EC2 / RDS / Redshift on a stop-overnight or stop-on-weekend schedule via EventBridge + Lambda. Spot for fault-tolerant batch. Auto-Scaling group with min=0 for development environments. The contract enumerates expected duty cycle for every long-running resource.
8. Record carbon impact in the contract. Each component contract emits a sustainability: block: chosen region tier, instance arch, storage tier, idle handling, and any deviations with rationale. The orchestrator's merge step aggregates these into the design summary so the user sees system-level sustainability posture.