aws-waf-cost-optimization-skill

When to Use

Apply this skill any time an agent makes a decision that has a recurring AWS bill attached: instance family choice, storage class, scaling policy, region pairing, networking topology, or commitment-based pricing. Cost is a first-class design pillar, not a post-hoc audit.

Trigger conditions:

• The orchestrator's solution-architect specialist is producing design.md and must record explicit cost trade-offs alongside the other pillars.
• A component contract under .claude/specs/<feature>/contracts/<name>.md declares a long-running resource (anything not strictly request-driven) — the contract must record the chosen pricing model and the rationale.
• The user requests a cost estimate, a Reserved-Instance / Savings-Plans review, or a "lower the bill" pass on an existing design.
• The implementation specialist is selecting between equivalent AWS services (e.g. SQS vs Kinesis, RDS vs Aurora, ALB vs NLB) and the cost differential is material.
• The discovery specialist is enumerating non-functional requirements and a cost ceiling, budget threshold, or unit-economics target is in scope.
• The sustainability skill is recommending Graviton or scale-to-zero — verify the cost outcome is consistent with the user's commitment posture before agreeing.

Do not apply this skill to pricing decisions for non-AWS services, to one-shot operational expenses (e.g. a kms encrypt call inside a Lambda — covered by the per-invocation budget), or to per-request micro-optimisations that the workload's traffic pattern does not justify.

Procedure

1. Get authoritative pricing. Issue a cost MCP call (the aws-pricing server) for every priced resource. Cite the result via the aws-spec-grounding skill's <server>:<short-key> format. Stale or pretrained pricing is forbidden — pricing changes quarterly and inference is a costly source of error.
2. Pick the pricing model. Consult references/pricing-models.md. Default decision tree:
   • Steady-state, ≥12-month commitment tolerable → Compute Savings Plans (most flexible across instance family, region, OS). Record the commitment term and coverage target in the contract.
   • Steady-state, instance family stable for 1–3 years → Reserved Instances (Standard for max discount, Convertible for flexibility).
   • Fault-tolerant, interruption-tolerable → Spot, with Spot-Fleet diversification and a documented retry policy.
   • Bursty, sub-second wake → Lambda or Fargate (per-invocation pricing).
   • Default / not yet predictable → On-Demand, with an explicit "revisit at when usage data exists" item in tasks.
3. Right-size before committing. Use Compute Optimizer recommendations (via the cw MCP) on existing workloads, or measured peak from load tests on new ones. The contract records the actual percentile used (e.g. "p99 over 14 days") and the chosen instance size. Coordinate with the sustainability skill — Graviton + right-sizing is the same lever for both pillars.
4. Tier storage by access pattern. S3 lifecycle: Standard → Standard-IA after 30d → Glacier Instant Retrieval after 90d → Glacier Deep Archive after 180d, unless retrieval-time SLOs forbid. EBS gp3 over gp2 (separate IOPS/throughput billing eliminates over-provisioning waste). Apply CloudWatch Logs retention; never leave the default of "never expire". Each lifecycle policy is recorded in the contract's cost: block.
5. Cap data-egress costs. Data leaving an AWS region or AWS as a whole is the largest hidden line item in many bills. Use VPC endpoints (Gateway endpoints for S3/DynamoDB are free; Interface endpoints have an hourly charge that almost always pays for itself versus NAT-Gateway egress). Co-locate data and compute in the same AZ where the workload's availability profile permits. Cache at the edge (CloudFront) instead of repeatedly serving from origin. Each cross-region or internet-egress data path is enumerated in the cost: block with an estimated monthly volume.
6. Tag for allocation. Every component contract declares tags: Project, Environment, Owner, CostCenter, plus any workload-specific tag the customer's tagging policy demands. Cost allocation tags must be enabled at the account / Organizations level — note this in the design summary if not already configured.
7. Set budget alarms. Each design declares at least one AWS Budgets alarm threshold (typically 80% of the projected monthly run-rate as the warning, 100% as the action threshold). The action is documented (notify owner; do not auto-shut-down without an explicit user opt-in).
8. Record cost projection in the contract. The cost: block emits: chosen pricing model, monthly run-rate range (rough order of magnitude is acceptable when pricing API is degraded — use the cost-rom-only marker), commitment term and coverage if applicable, cost-allocation tags, and any deviation from the default decision tree with rationale. The orchestrator's merge step aggregates these into a system-level projection in the design summary.