Cost & Performance in Production

Right-size relentlessly, buy commitments for steady load, and treat the AWS bill as a metric you own — cheap and fast are usually the same change.

In production, cost and performance aren't opposites — an over-provisioned service is both slow to reason about and expensive. Seniors treat the bill as a first-class operational metric with an owner and a trend line.

Levers that actually move the needle

  • Right-size on evidence. Use Compute Optimizer and CloudWatch to find the p99 CPU/memory, then size for that — not for the peak-of-peaks you imagined.
  • Commit to steady load. Savings Plans and Reserved capacity cut 30–70% off compute you know you'll run 24/7. Keep on-demand and Spot for the variable top.
  • Spot for the interruptible. Fargate Spot and EC2 Spot slash cost for batch, async workers, and stateless capacity that tolerates being reclaimed.
  • Scale to the signal. Target-tracking auto scaling (e.g. keep CPU at 60%) adds capacity for a traffic spike and gives it back afterward.
  • Set budgets & anomaly alerts. AWS Budgets + Cost Anomaly Detection page you when spend drifts before the end-of-month surprise.

The performance dividend

Caching at CloudFront, connection pooling to RDS, and a smaller-but-busier fleet often improve latency and lower cost at once. Measure before and after — a guess is not an optimization.

Example

Example · json
// Target-tracking auto scaling: keep Fargate CPU near 60%
{
  "PolicyName": "myapp-cpu-target",
  "PolicyType": "TargetTrackingScaling",
  "ResourceId": "service/myapp-prod/web",
  "ScalableDimension": "ecs:service:DesiredCount",
  "ServiceNamespace": "ecs",
  "TargetTrackingScalingPolicyConfiguration": {
    "TargetValue": 60.0,
    "PredefinedMetricSpecification": {
      "PredefinedMetricType": "ECSServiceAverageCPUUtilization"
    },
    "ScaleInCooldown": 300,
    "ScaleOutCooldown": 60
  }
}

When to use it

  • An ops team right-sizes 20 EC2 instances from m5.xlarge to t3.large using AWS Compute Optimizer recommendations, saving $800/month.
  • A company buys a 1-year Compute Savings Plan after analysing baseline usage, cutting steady-state EC2 and Fargate costs by 35%.
  • A team enables S3 Intelligent-Tiering on an archive bucket holding 5 TB of logs, reducing storage costs without changing the access pattern.

More examples

Check Compute Optimizer recommendations

Lists EC2 instances flagged as over-provisioned and the recommended smaller type, showing where right-sizing will save money.

Example · bash
aws compute-optimizer get-ec2-instance-recommendations \
  --query 'instanceRecommendations[*].[instanceArn,finding,recommendationOptions[0].instanceType]' \
  --output table

Enable S3 Intelligent-Tiering

Enables Intelligent-Tiering on a logs bucket so objects not accessed for 90 days automatically move to the cheaper archive tier.

Example · bash
aws s3api put-bucket-intelligent-tiering-configuration \
  --bucket my-logs-bucket \
  --id EntireBucket \
  --intelligent-tiering-configuration \
    'Id=EntireBucket,Status=Enabled,Tierings=[{Days=90,AccessTier=ARCHIVE_ACCESS}]'

Review Savings Plan coverage

Shows the percentage of compute hours covered by Savings Plans so you can identify whether buying more commitments makes sense.

Example · bash
aws ce get-savings-plans-coverage \
  --time-period Start=$(date -d '30 days ago' +%Y-%m-%d),End=$(date +%Y-%m-%d) \
  --granularity MONTHLY \
  --query 'SavingsPlansCoverages[0].Coverage.CoverageHoursPercentage'

Discussion

  • Be the first to comment on this lesson.