Laws I–IV: Design, measure, and simplify

• I. Make cost a non-functional requirement — Budget targets and cost constraints belong in the architecture review alongside latency, availability, and security. "We will figure out cost later" always means "we will pay more than we should." Define cost ceilings in the design phase.
• II. Systems that last align cost to business revenue — Costs should scale proportionally with revenue, not faster. If revenue doubles, costs should roughly double — not triple. When costs grow faster than revenue, the business model breaks at scale. Design cost/unit (cost per transaction, per user, per API call) into the architecture.
• III. Architecting is a series of trade-offs — Every architecture decision trades cost, performance, reliability, and maintainability. There is no free lunch. Fully managed services (RDS, DynamoDB) are expensive but save operational overhead. Self-managed (EC2 + Postgres) is cheaper but requires expertise. Choose explicitly, not by default.
• IV. Unobserved systems lead to unknown costs — You cannot optimize what you cannot measure. Every resource must have a tag (team, product, environment). Cost must be visible per service, per feature, per customer tier. "Cloud costs" is not an acceptable line item — break it down until you can make decisions.

Laws V–VII: Rightsize, optimize at every layer, and never sacrifice sustainability

• V. Cost-aware architectures implement cost controls — Budget alerts, spending limits, and automatic shutdown of non-production environments. Developers get weekly cost reports for their services. Anomaly detection alerts when costs spike unexpectedly. Never wait for the monthly bill.
• VI. Cost optimization is iterative — You do not optimize cost once and forget it. As usage patterns change, right-sizing becomes wrong-sizing. Schedule quarterly cost reviews. Identify the top 3 cost drivers every quarter and ask if they are proportional to the value they provide.
• VII. Be a part of a cost-aware culture — Cost awareness cannot live only in the ops team. Developers need to understand what their architecture choices cost. Show engineers their service's monthly bill. Make cost visible in sprint reviews. "That DynamoDB table costs $12k/month" changes engineering conversations.

Common cost anti-patterns

• Idle resources — Development and staging environments running 24/7 at production scale. Common fix: auto-shutdown non-production environments at 7 PM, restart at 8 AM. Typical savings: 60-75% on non-prod environments.
• Wrong instance types — Using compute-optimized instances for memory-intensive workloads, or t3.xlarge for a service that uses 5% CPU. Fix: Compute Optimizer or Datadog metrics → rightsize to actual p95 usage + 30% headroom.
• Data transfer costs — The most underestimated AWS cost line item. Cross-AZ traffic, VPC to internet, NAT gateway egress. Fix: place related services in the same AZ (latency vs. availability trade-off), use VPC endpoints for S3/DynamoDB, compress payloads.
• Unoptimized storage — S3 buckets with 5 years of logs in Standard storage class. DynamoDB tables with on-demand pricing for predictable workloads. Fix: S3 Intelligent Tiering, DynamoDB provisioned capacity with autoscaling, EBS gp2 → gp3 migration (same performance, 20% cheaper).
• Missing cache layer — N+1 database queries, repeated API calls to expensive services, no CDN on static assets. A single Redis cache can reduce RDS costs by 60% by absorbing read traffic.