Cost Optimization and the Well-Architected Framework

You cannot optimize what you cannot see

Set up visibility first.

Tag consistently (team, env, service, cost-center) and activate them as cost allocation tags. Enforce with tag policies and SCPs.

Pricing models

Rule of thumb: commit to your steady baseline (say 60 to 70% of usage), leave the variable part on-demand, and run interruptible work on Spot. Do not commit before right-sizing.

Where money usually leaks

1. Idle and oversized resources: unused EC2, unattached EBS volumes, old snapshots, idle load balancers, dev environments running overnight.
2. NAT gateway data processing: add S3 and DynamoDB gateway endpoints; use interface endpoints for heavy services; keep traffic within an AZ.
3. Data transfer: cross-AZ, cross-region and internet egress. Use CloudFront in front of origins, keep chatty services in the same AZ when safe.
4. Storage: S3 data left in Standard forever, old log groups, over-provisioned IOPS.
5. Logging: CloudWatch Logs ingestion is costly; set retention, lower log levels, and sample.
6. Over-provisioned databases: check Performance Insights before upsizing.

Quick wins by service

EC2 and containers

• Right-size using Compute Optimizer; move to Graviton (arm64) for often 20% or better price-performance.
• Schedule non-production shutdowns (Instance Scheduler, EventBridge Scheduler).
• Use Spot with diversified instance types and capacity-optimized allocation.

S3

• Use Lifecycle rules and Intelligent-Tiering when access patterns are unknown.
• Abort incomplete multipart uploads; expire old versions.

{
  "Rules": [{
    "ID": "tier-and-expire",
    "Status": "Enabled",
    "Filter": { "Prefix": "logs/" },
    "Transitions": [
      { "Days": 30, "StorageClass": "STANDARD_IA" },
      { "Days": 90, "StorageClass": "GLACIER_IR" }
    ],
    "Expiration": { "Days": 365 },
    "AbortIncompleteMultipartUpload": { "DaysAfterInitiation": 7 }
  }]
}

Databases

• Use Aurora Serverless v2 or schedule stop for dev databases; delete old manual snapshots.
• DynamoDB: pick on-demand or provisioned correctly; use Standard-IA table class for rarely read tables; enable TTL.

Lambda

• Tune memory with AWS Lambda Power Tuning: more memory can mean shorter duration and lower total cost.
• Use arm64 and avoid unnecessary invocations (filter events at the source).

EBS

• Move gp2 to gp3 (cheaper, independent IOPS); delete unattached volumes and unused snapshots.

Build cost into engineering culture

• Show each team its own spend (showback), then consider chargeback.
• Set budgets with alerts per account and per team.
• Estimate cost in design reviews with the AWS Pricing Calculator.
• Track unit economics, such as cost per order or per 1,000 requests, not only the total bill.
• Review monthly: top ten cost lines, anomalies, commitment coverage and utilization.

The Well-Architected Framework

A structured way to review a workload against six pillars.

Use the AWS Well-Architected Tool to run structured reviews, record risks and track improvements. Do it at design time and again before major launches.

Trade-offs to articulate in interviews

• Cost versus reliability: multi-region active-active doubles cost; justify it with RTO and RPO.
• Managed versus self-managed: managed services cost more per unit but save engineering time and reduce risk.
• Serverless versus containers: serverless wins for spiky or low traffic; steady heavy load is often cheaper on containers or instances.
• Commitment versus flexibility: Savings Plans save money but reduce agility.

Worked cost review: cost per accepted order

A monthly bill alone cannot show whether efficiency improved. Suppose a hypothetical application costs 300 currency units to process 10,000 accepted orders. Its cost per accepted order is 0.03. If next month's bill is 450 for 20,000 accepted orders, total spend increased while unit cost fell to 0.0225.

Use a denominator that reflects useful work, and report reliability alongside it. A cheaper system that loses orders has not improved. These values illustrate arithmetic; they are not AWS prices.

Investigate before purchasing a commitment

1. Compare costs by service, account, Region, and usage type.
2. Connect the change to traffic, releases, data movement, and retention.
3. Remove unused resources and improve inefficient work.
4. Measure the resulting steady baseline over a representative period.
5. Only then evaluate commitments and their utilization risk.

An architecture tradeoff exercise

Compare a private container service using NAT with one using selected VPC endpoints. List hourly infrastructure, processed data, cross-AZ transfer, and necessary third-party access. Endpoints may remove some NAT traffic but cannot replace every external dependency. Use current regional prices and real traffic volumes; a slogan such as “private endpoints are always cheaper” is inadequate.

A review with measurable outcomes

Deliverable: propose one improvement, forecast its effects, implement it in a suitable lab or controlled release, then compare cost, latency, and errors. Document the tradeoff instead of claiming success from a lower bill alone.

Remember this

• Tag, measure, and alert before optimizing.
• Right-size first, then commit to the steady baseline, and use Spot for tolerant work.
• Watch NAT, data transfer, logs and idle resources; they are the usual surprises.
• Use the six Well-Architected pillars to review designs and explain trade-offs.