Part 073 — Compute and Storage Cost Engineering and Unit Economics

Cost optimization is not "make everything cheaper."

Cost optimization is the engineering discipline of buying the right reliability, performance, capacity, and recovery characteristics for the workload—without waste.

A junior engineer asks:

How do we reduce this AWS bill?

A top-tier engineer asks:

What is the unit cost of serving this workload at the required SLO, RPO, RTO, and security posture—and which part of the architecture determines that unit cost?

For compute and storage, cost is a design signal.

It tells you:

• whether instances are oversized
• whether storage lifecycle is wrong
• whether snapshots are accumulating
• whether S3 versions are exploding
• whether file systems are idle
• whether backups are over-retained
• whether Spot interruption risk is worth it
• whether Savings Plans are under- or over-committed
• whether a cache is still cheaper than recomputation
• whether a derived dataset should be rebuilt instead of protected forever

Cost engineering is not finance-only.

It is architecture feedback.

1. Problem yang Diselesaikan

Part ini membahas:

• FinOps mental model for compute/storage
• unit economics
• cost allocation and tagging
• AWS Cost Explorer and rightsizing recommendations
• AWS Compute Optimizer
• Cost and Usage Reports / Data Exports
• AWS Budgets and budget actions
• Savings Plans vs Reserved Instances
• Spot economics and interruption-aware design
• EC2/EBS/S3/EFS/FSx/AWS Backup cost drivers
• storage lifecycle economics
• snapshot/version/backup cost traps
• cost dashboards
• cost anomaly response
• architecture-level cost optimization runbooks

2. Mental Model

2.1 Cost is a workload SLO constraint

Every workload has an implicit cost objective:

serve X requests / store Y data / recover within Z time at acceptable cost

Make it explicit:

service: evidence-api
unit: accepted-evidence-upload
targetUnitCost: <= $0.015
included:
  - api compute
  - S3 storage and requests
  - KMS requests
  - malware scan compute
  - backup/replication
  - logs/audit
  - support overhead estimate
excluded:
  - shared platform baseline

2.2 Unit economics beats aggregate bill

Aggregate bill says:

S3 cost is $40,000/month

Unit economics says:

$0.002 per uploaded object
$12 per TB-month retained under WORM
$0.08 per training run checkpoint
$0.40 per report generated

Unit economics lets engineers make design trade-offs.

2.3 Cost has four dimensions

Example:

High EC2 bill can be:
- too much traffic
- wrong instance family
- low utilization
- no Savings Plan
- retries due storage latency
- background job bug
- bad autoscaling metric

2.4 Cheap can be expensive

Cheaper storage class can increase total cost if:

• retrieval cost high
• request amplification high
• restore too slow
• lifecycle transition cost outweighs savings
• app keeps re-reading cold data
• wrong archive class breaks RTO

Cheaper compute can increase total cost if:

• job runs longer
• retries more
• less efficient CPU architecture
• memory pressure causes thrash
• Spot interruptions cause reruns without checkpointing

2.5 Optimize after measuring

Cost optimization without measurement becomes random austerity.

Sequence:

allocate -> observe -> attribute -> model -> optimize -> validate -> guardrail

3. Cost Allocation

3.1 Ownership is prerequisite

Before optimizing, answer:

• who owns this resource?
• which service uses it?
• which environment?
• what data class?
• is it source-of-truth/cache/scratch?
• what business unit pays?
• what is the expiration date?
• which workload unit does it support?

3.2 Required tags

Baseline tags:

Owner:
Service:
Environment:
CostCenter:
DataClass:
BackupTier:
Workload:
ExpiresAt:
ManagedBy:

For storage:

DataRole: source-of-truth|cache|scratch|derived|backup|archive
Retention:
Rpo:
Rto:

For compute:

ComputeRole: web|worker|batch|training|cache|db-self-managed
CapacityClass: baseline|burst|spot|reserved|dr

3.3 Cost allocation tags

AWS cost allocation tags allow resource costs to be organized in billing reports after activated.

Important:

• tags must be applied to resources
• user-defined cost allocation tags must be activated
• tag drift creates unattributed cost
• not all resources have perfect tag coverage
• shared resources need split allocation

3.4 Shared cost allocation

Shared resources:

• NAT gateways
• load balancers
• shared EKS nodes
• EFS/FSx shared file systems
• S3 shared buckets
• backup vaults
• logging pipelines
• CI/CD runners

Allocation strategies:

• by request count
• by bytes stored
• by bytes transferred
• by CPU/memory requested
• by namespace/team
• by object prefix
• by volume/share owner
• by equal split only if no better signal

3.5 Split cost allocation

AWS Cost and Usage Reports can include split cost allocation data for container workloads. Split cost allocation helps allocate EC2 instance cost to ECS/EKS containers/tasks based on usage telemetry.

Use when:

• shared EC2 nodes host many services
• container cost ownership matters
• teams argue about shared cluster bill
• unit cost per service is needed

3.6 Untagged cost is operational debt

Track:

untagged cost % by account
untagged EC2/EBS/EFS/FSx
untagged S3 buckets
untagged snapshots
untagged backup recovery points

Goal for production:

critical resources: 100% ownership tags
shared cost: documented allocation model

4. Cost Data Sources

4.1 Cost Explorer

Cost Explorer is useful for:

• interactive cost trend analysis
• rightsizing recommendations
• service-level cost breakdown
• account/tag filtering
• commitment usage overview
• quick anomaly investigation

Cost Explorer rightsizing recommendations analyze EC2 resources and usage to show opportunities to reduce spend by downsizing or terminating instances.

Use it for:

• initial cost review
• monthly rightsizing
• EC2 waste discovery
• team cost conversations

4.2 Cost and Usage Reports / Data Exports

Cost and Usage Reports track AWS usage and estimated charges, with line items for unique combinations of AWS products, usage type, and operation. Reports can be delivered to S3 and updated up to three times per day.

Use CUR/Data Exports for:

• detailed analysis
• unit cost modeling
• Athena/QuickSight dashboards
• chargeback/showback
• anomaly investigation
• long-term cost trends
• split cost allocation
• storage class/version cost analysis

4.3 Compute Optimizer

AWS Compute Optimizer analyzes configuration and utilization metrics for resources such as EC2 instances, Auto Scaling groups, EBS volumes, Lambda functions, and ECS services on Fargate, then generates recommendations to reduce cost and improve performance.

Use it for:

• EC2 rightsizing
• ASG recommendations
• EBS volume recommendations
• Lambda memory recommendations
• ECS Fargate recommendations
• under/over-provisioned detection

4.4 AWS Budgets

AWS Budgets can create cost, usage, RI, and Savings Plans budgets. Cost budgets set spending limits and can alert when costs approach or exceed thresholds.

Use for:

• monthly spend guardrails
• forecasted spend alerts
• usage caps
• team budgets
• non-prod runaway alerts
• commitment utilization alerts
• budget actions where safe

4.5 Cost Optimization Hub

Cost Optimization Hub consolidates optimization recommendations. It can ingest recommendations from Compute Optimizer and other cost optimization sources.

Use for:

• centralized opportunity tracking
• FinOps backlog
• savings prioritization
• owner assignment
• executive reporting

4.6 S3 Storage Lens

S3 Storage Lens provides organization-wide visibility into object storage usage and activity. It can identify cost optimization opportunities such as buckets missing lifecycle rules for incomplete multipart uploads and data protection gaps like missing versioning/replication.

Use for:

• noncurrent version growth
• incomplete multipart uploads
• delete marker count
• bucket-level waste
• storage class distribution
• lifecycle opportunity
• data protection posture
• prefix/bucket trends

5. Compute Cost Engineering

5.1 EC2 cost drivers

EC2 cost depends on:

• instance type/family/size
• purchase option
• running hours
• OS/license
• Region/AZ
• data transfer
• EBS volumes
• EBS snapshots
• load balancers/NAT
• idle instances
• overprovisioned Auto Scaling
• unused reservations/commitments

5.2 Rightsizing EC2

Inputs:

• CPU p50/p95/p99
• memory p95/p99
• network throughput
• EBS throughput/IOPS
• request latency
• queue lag
• GC/heap pressure
• burst behavior
• seasonality
• deployment safety margin

Do not downsize on CPU alone.

Example:

CPU 10%, memory 92% -> not overprovisioned
CPU 10%, network 80% -> maybe network-bound
CPU 10%, p99 latency high -> investigate dependency
CPU 10%, memory 20%, network low -> downsize candidate

5.3 Instance family selection

Cost optimization includes choosing correct family:

• compute optimized for CPU-bound
• memory optimized for in-memory/cache
• storage optimized for local disk/IO
• general purpose for balanced
• GPU/accelerated for ML/HPC
• Graviton/ARM where app/toolchain supports

Benchmark per workload.

5.4 Auto Scaling economics

Bad scaling:

• min capacity too high
• max too low causing SLO breach
• scale-in too conservative
• wrong metric
• target tracking on CPU for I/O-bound workload
• scheduled scaling missing predictable peak
• warm pool oversized
• over-diversified low-utilization fleets

Good scaling:

• scale by user-impacting pressure
• scheduled scale for predictable peaks
• cooldown aligned with startup time
• graceful drain
• min capacity justified by SLO
• capacity diversified for Spot/On-Demand
• standby/warm pool based on startup RTO

5.5 Savings Plans

Compute Savings Plans provide discounted compute pricing in exchange for a consistent usage commitment measured in $/hour, with flexibility across compute usage compared with more configuration-specific commitments.

Use for:

• stable baseline compute
• services running 24/7
• multi-family/multi-Region flexibility needs
• mature workloads with predictable spend

Avoid overcommitment:

commitment should cover baseline, not peak

5.6 Reserved Instances

EC2 Reserved Instances provide a billing discount for matching On-Demand usage attributes. They are not physical instances.

Use when:

• specific instance family/Region/AZ usage stable
• Standard RI commitment acceptable
• Convertible RI flexibility valuable
• Capacity Reservation or zonal capacity properties needed separately

5.7 Spot Instances

Spot Instances are cost-effective when workload is flexible and can be interrupted.

Use for:

• batch
• stateless workers
• CI
• ML training with checkpoints
• rendering
• analytics
• queue consumers

Do not use Spot for:

• single critical writer
• stateful primary without checkpoint/failover
• workloads that cannot handle interruption
• low-latency fixed-capacity critical path unless mixed with On-Demand

5.8 Spot engineering

Spot savings require interruption-aware design:

• multiple instance types
• multiple AZs
• capacity-optimized allocation
• checkpointing
• idempotent jobs
• graceful termination on interruption notice
• queue visibility timeout
• retry budget
• On-Demand baseline
• max interruption rate SLO

Cost equation:

effective_spot_savings =
  spot_discount
  - recompute_cost
  - checkpoint_overhead
  - operational_complexity
  - capacity_unavailability_risk

5.9 Idle compute cleanup

Find:

• EC2 instances with low CPU/network for N days
• stopped instances with attached EBS
• old dev/test
• orphan Auto Scaling groups
• idle load balancers
• unused NAT gateways
• ECS/EKS clusters with no workload
• abandoned bastions

Use tags:

ExpiresAt:
AutoStop:
Environment:
Owner:

6. EBS Cost Engineering

6.1 EBS cost drivers

• provisioned GB
• volume type
• provisioned IOPS
• provisioned throughput
• snapshots
• Fast Snapshot Restore
• volume copies
• unattached volumes
• overprovisioned gp3/io2
• idle test restore volumes

6.2 gp3 rightsizing

gp3 decouples storage capacity from IOPS/throughput.

Optimize:

• reduce overprovisioned IOPS
• reduce overprovisioned throughput
• avoid upsizing only for performance if gp3 tuning is enough
• monitor actual IOPS/throughput
• benchmark latency

6.3 io2/io2 Block Express

Use only when:

• very high IOPS/durability/performance needed
• database/app requires it
• latency SLO justifies cost
• managed database alternative considered

Do not keep io2 because "it was safer."

6.4 Unattached volumes

Unattached EBS volumes still cost money.

Runbook:

1. list unattached volumes
2. identify owner
3. check tags/last attach
4. snapshot if needed
5. delete after approval/expiry
6. add lifecycle guardrail

6.5 Snapshot cost

Snapshot cost grows with changed blocks retained.

Drivers:

• frequent snapshots
• high churn volumes
• long retention
• many AMIs
• copied snapshots
• restore test volumes left behind
• orphan snapshots after AMI deregistration

Optimization:

• lifecycle policies
• owner tags
• retention by data class
• delete old AMIs with snapshots
• avoid backing up cache/scratch volumes
• use AWS Backup/DLM policies

6.6 Fast Snapshot Restore cost

FSR should be targeted.

Use only for:

• critical recovery points
• specific AZs
• specific duration
• game-day-proven need

Disable when no longer needed.

7. S3 Cost Engineering

7.1 S3 cost drivers

• storage GB-month
• storage class
• request count
• data retrieval
• lifecycle transition
• replication
• data transfer
• inventory/analytics
• Storage Lens advanced metrics
• KMS requests
• noncurrent versions
• delete markers
• incomplete multipart uploads
• object count/small objects
• AWS Backup for S3

7.2 Storage class selection

Choose by access pattern and recovery objective.

Questions:

• access frequency?
• latency requirement?
• minimum storage duration?
• retrieval cost?
• object size?
• lifecycle transition cost?
• RTO?
• compliance retention?
• replication needs?

7.3 Intelligent-Tiering

Use when:

• access pattern unknown/changing
• object size/min duration fits
• monitoring/tiering cost justified
• team wants automatic access-tier optimization

Not always best for:

• tiny short-lived objects
• predictable lifecycle
• objects frequently deleted before minimum duration
• data with strict immediate retrieval but stable hot access

7.4 Noncurrent version cost

Versioning protects data but can be expensive.

Watch:

• noncurrent version bytes
• number of versions per key
• hot overwritten keys
• lifecycle retention
• Object Lock retained versions
• catalog version retention needs

Pattern:

immutable keys reduce noncurrent version cost

7.5 Incomplete multipart uploads

Incomplete multipart uploads store parts and cost money until aborted.

AWS recommends configuring lifecycle rules using AbortIncompleteMultipartUpload to minimize storage costs.

7.6 Small object cost

Small files can increase:

• request cost
• metadata overhead
• analytics inefficiency
• lifecycle transition cost
• minimum object storage overhead in some classes
• list/scan cost

Optimize:

• bundle/compact
• Parquet/ORC for analytics
• manifest/catalog
• avoid one object per tiny event if query path requires scanning
• batch writes

7.7 KMS request cost

SSE-KMS can increase cost with high request rates.

Mitigate:

• use bucket keys where appropriate
• reduce small-object request amplification
• cache metadata
• batch operations
• understand security requirement
• monitor KMS throttles and cost

7.8 S3 lifecycle economics

Lifecycle must be recovery-aware.

Bad:

transition everything after 30 days

Better:

prefix: raw/events/
transition: Standard-IA after 30d
archive: Glacier Flexible after 180d
retain noncurrent: 45d
rationale: DB PITR 35d + margin

7.9 S3 cost runbook

1. Break down by bucket/prefix/storage class.
2. Check current vs noncurrent bytes.
3. Check incomplete multipart uploads.
4. Check request-heavy prefixes.
5. Check KMS requests.
6. Check replication destinations.
7. Check lifecycle rules.
8. Check object count/small objects.
9. Propose lifecycle/compaction/version changes.
10. Validate against RPO/RTO/compliance.

8. EFS Cost Engineering

8.1 EFS cost drivers

• storage bytes by class
• throughput mode
• provisioned throughput
• Elastic Throughput
• lifecycle storage classes
• backup storage
• replication destination
• data transfer/cross-AZ access
• idle file systems
• large temp/cache directories

8.2 EFS lifecycle

EFS lifecycle management can move files to lower-cost storage classes based on access patterns.

Use for:

• user home directories
• large cold file sets
• reports/archives
• mixed hot/cold file storage

Caution:

• first access latency/cost
• app timeout
• RTO interaction
• compliance retention
• files that appear cold but are needed in batch

8.3 Throughput mode economics

Choose based on workload:

• Bursting for many spiky workloads
• Provisioned when consistent throughput required independent of storage size
• Elastic Throughput where variable workload needs automatic scaling and cost model fits

Monitor:

• PercentIOLimit
• permitted throughput
• metered IO
• app latency
• cost vs performance

8.4 EFS idle cleanup

Find:

• file systems with no client connections
• low bytes but active backup
• dev/test leftovers
• no owner tag
• replicas no longer used
• access points unused

Do not delete source-of-truth without owner approval and backup.

9. FSx Cost Engineering

9.1 FSx cost drivers

Varies by family:

• storage capacity/type
• throughput capacity
• SSD/HDD/capacity pool
• provisioned IOPS
• backups
• snapshots/clones
• data transfer
• file system idle time
• replication
• metadata-heavy workload
• DR standby capacity

9.2 FSx Windows

Optimize:

• SSD vs HDD
• throughput capacity
• shadow copy storage
• backup retention
• idle shares
• Single-AZ vs Multi-AZ by criticality
• noisy batch separated from interactive workload

9.3 FSx Lustre

Optimize:

• scratch lifetime
• persistent vs scratch
• storage class
• capacity sized to working set/performance
• delete after campaign
• export outputs before teardown
• avoid tiny-file metadata bottleneck
• checkpoint cost vs rerun cost

9.4 FSx ONTAP

Optimize:

• SSD active tier
• capacity pool tiering
• volume boundaries
• snapshot/clone sprawl
• storage efficiency
• backup retention
• tiering recall cost/latency
• SVM/file system consolidation vs isolation

9.5 FSx OpenZFS

Optimize:

• throughput capacity
• provisioned IOPS
• snapshot/clone lifecycle
• clone TTL
• volumes per data class
• backup/replication only where needed
• dev/test clone cleanup

9.6 Amazon File Cache

Optimize:

• campaign lifetime
• active working set size
• throughput tier
• warmup cost
• source reload cost
• idle cache alarm
• eviction churn
• output export discipline

10. Backup and DR Cost Engineering

10.1 Backup cost drivers

• recovery point storage
• backup frequency
• retention
• cross-region copy
• cross-account copy
• cold storage
• restore testing
• restored test resources
• vault locks retaining too long
• duplicate backup systems

10.2 RPO cost

Lower RPO usually costs more:

hourly backup > daily backup
continuous backup > periodic backup
replication + backup > backup alone

Match to data class.

10.3 RTO cost

Lower RTO costs more:

• warm standby
• active-active
• Fast Snapshot Restore
• provisioned standby capacity
• prewarmed caches
• replicas
• reserved capacity
• frequent restore tests

10.4 Restore testing cost

Restore testing creates resources.

Control:

• limited scope
• scheduled cleanup
• right-sized test environment
• sample workloads
• dedicated test account
• cost budget for recovery readiness

10.5 Duplicate protection

Detect:

• AWS Backup + DLM + manual snapshots all backing same volume
• S3 versioning + replication + backup + overly long lifecycle with no data class reason
• FSx snapshots + backups + clones retained forever
• EFS backup plus DataSync archive plus unknown manual copy

Duplication can be justified. Undocumented duplication is waste.

11. Budgets and Guardrails

11.1 Budget types

Use:

• cost budgets
• usage budgets
• RI utilization/coverage budgets
• Savings Plans utilization/coverage budgets

11.2 Budget design

Create budgets by:

• account
• environment
• service
• team
• workload
• data class
• non-prod
• anomaly category

Examples:

dev monthly budget
backup storage budget
S3 noncurrent version budget
GPU training campaign budget
FSx Lustre campaign budget

11.3 Budget actions

AWS Budgets can be configured to notify and take actions when thresholds are reached.

Use actions carefully:

Safe:

• notify
• create OpsItem
• apply SCP to sandbox account after approval
• stop non-prod instances after approval

Risky:

• stop production compute automatically
• delete resources
• disable backups
• remove capacity during incident

11.4 Forecast budgets

Use forecasted thresholds for early warning:

alert if forecasted month-end > 120% of budget

11.5 Cost anomaly detection

Use anomaly detection for unexpected spend spikes.

Response:

1. identify service/account/resource
2. check recent deployment/change
3. check usage metrics
4. classify legitimate vs bug/waste/incident
5. mitigate
6. add guardrail

12. Unit Cost Modeling

12.1 Define the unit

Examples:

• API request
• successful upload
• GB processed
• ML training run
• report generated
• tenant-month
• active user-month
• backup-protected TB-month
• recovered workload game day

12.2 Assign cost components

Example upload unit:

unit: evidence-upload
components:
  compute: ECS/EC2 request processing
  storage: S3 object bytes
  requests: S3 PUT/GET/HEAD
  kms: encrypt/decrypt requests
  scan: malware scanner compute
  metadata: database write
  backup: replication + object lock retention
  logs: CloudWatch/S3 audit logs

12.3 Formula

unit_cost =
  allocated_compute_cost / successful_units
+ allocated_storage_cost / successful_units
+ request_cost / successful_units
+ backup_and_dr_cost / successful_units
+ observability_cost / successful_units

12.4 Marginal vs fixed cost

Fixed:

• baseline EC2
• NAT gateway
• ALB
• FSx minimum capacity
• standby environment

Marginal:

• per-request compute
• S3 requests
• storage growth
• KMS calls
• data transfer
• backup per GB

Scale decisions depend on marginal cost.

12.5 Cost per successful job

For batch/ML:

cost_per_success =
  all_attempt_compute
+ storage/cache
+ failed_attempt_recompute
+ checkpoints
+ output storage
+ cleanup overhead

Spot may reduce per-hour cost but increase failed-attempt cost if checkpointing poor.

12.6 Cost-to-serve dashboard

For each critical service:

monthly cost
business units
unit count
unit cost
gross margin impact
top 5 cost components
change vs previous period
optimization backlog

13. Optimization Runbooks

13.1 Monthly compute rightsizing

1. Pull Compute Optimizer recommendations.
2. Cross-check Cost Explorer rightsizing.
3. Review p95/p99 CPU, memory, network, EBS.
4. Exclude workloads in recent change/incident.
5. Test new size in staging/canary.
6. Deploy via IaC.
7. Monitor SLO.
8. Record savings.

13.2 Savings Plans review

1. Identify stable baseline spend.
2. Exclude volatile/Spot/campaign workloads.
3. Model 1-year/3-year risk.
4. Check current utilization/coverage.
5. Commit below conservative baseline.
6. Review monthly.
7. Avoid covering future hoped-for usage.

13.3 S3 version cost review

1. Use Storage Lens/Inventory.
2. Identify buckets with high noncurrent bytes.
3. Classify data class.
4. Validate DB/catalog PITR window.
5. Adjust lifecycle safely.
6. Move to immutable keys where possible.
7. Test restore before expiration.

13.4 Snapshot cleanup

1. List snapshots without owner/AMI association.
2. Identify retention policy.
3. Check if locked/compliance.
4. Check latest restore point alternative.
5. Delete only expired/unneeded.
6. Add DLM/AWS Backup policy.
7. Monitor recurring creation.

13.5 File system idle review

1. Find EFS/FSx with no clients/low IO.
2. Check data role.
3. Confirm owner.
4. Backup/export if source-of-truth.
5. Delete if disposable/expired.
6. Downsize throughput/storage where supported.
7. Add expiry tags.

13.6 Cost anomaly incident

1. Identify service/account/tag.
2. Check deployment and traffic.
3. Check resource creation spike.
4. Check storage growth/version/snapshot.
5. Stop runaway job if safe.
6. Notify owner.
7. Add guardrail.

14. Anti-Patterns

14.1 Cutting reliability to save cost

Disabling backups, replication, or monitoring to reduce bill can create catastrophic risk.

Optimize waste first.

14.2 Overcommit Savings Plans

Buying commitment for peak usage can waste money if usage drops.

Cover baseline.

14.3 Backing up cache forever

If it can be rebuilt, do not retain it like source-of-truth.

14.4 No owner tags

Unowned cost becomes permanent.

14.5 Cost-only rightsizing

Downsize without checking memory/network/EBS/app latency.

14.6 S3 lifecycle without recovery review

Deleting noncurrent versions too early breaks restore.

14.7 Idle DR environment with no test

If you pay for standby, test it.

14.8 Optimizing cents while wasting engineering weeks

Sometimes the cheapest AWS bill creates the most expensive engineering system.

15. Dashboards

15.1 Executive FinOps dashboard

• spend by account/team/service
• forecast vs budget
• top movers
• commitment utilization
• savings realized
• optimization backlog
• untagged spend
• unit cost trends

15.2 Compute cost dashboard

• EC2 spend by service
• utilization p95
• rightsizing opportunities
• Savings Plans coverage/utilization
• RI coverage/utilization
• Spot usage/interruption
• idle instances
• ASG min/max utilization

15.3 Storage cost dashboard

• S3 bytes by class
• noncurrent version bytes
• incomplete multipart uploads
• EBS unattached volumes
• snapshot growth
• EFS/FSx storage and throughput
• backup storage
• stale test restores
• replication cost

15.4 Unit economics dashboard

• cost per request
• cost per upload
• cost per GB processed
• cost per training run
• cost per protected TB
• cost per tenant
• error/retry cost
• waste per service

15.5 Guardrail dashboard

• budgets breached
• forecast breaches
• untagged cost
• expired resources still running
• protected resources without cost owner
• resources excluded from backup
• exceptions expiring

16. Game Days

Scenario 1 — S3 cost spike

Inject:

• high noncurrent versions or incomplete multipart uploads

Expected:

• Storage Lens/Inventory detects
• lifecycle proposal created
• restore impact reviewed
• cleanup safe

Scenario 2 — EC2 overprovisioned fleet

Expected:

• Compute Optimizer recommendation reviewed
• canary downsize
• SLO unchanged
• savings recorded

Scenario 3 — Spot interruption campaign

Expected:

• jobs checkpoint
• interruption handled
• cost per successful job measured
• retry cost visible

Scenario 4 — Budget forecast breach

Expected:

• alert triggers
• owner identified
• spend driver found
• safe mitigation
• budget action review

Scenario 5 — DR cost review

Expected:

• standby capacity justified by RTO
• idle resources identified
• restore tests still funded
• no critical protection removed

17. Design Checklist

17.1 Ownership

• Required tags enforced.
• Cost allocation tags activated.
• Shared cost allocation model documented.
• Untagged cost dashboard exists.
• Owner notified on anomalies.

17.2 Compute

• Compute Optimizer reviewed monthly.
• Rightsizing considers CPU/memory/network/EBS/SLO.
• Savings Plans cover baseline only.
• Spot workloads are interruption-safe.
• Idle compute cleanup exists.
• ASG min/max justified.

17.3 Storage

• S3 Storage Lens/Inventory used.
• Noncurrent version lifecycle reviewed.
• Incomplete multipart cleanup configured.
• EBS snapshots managed by policy.
• Unattached volumes reviewed.
• EFS/FSx idle review exists.
• Backup retention maps to data class.

17.4 Finance operations

• Budgets by account/team/service.
• Forecast alerts configured.
• Cost anomaly workflow exists.
• Unit cost model for critical workloads.
• Optimization backlog tracked.
• Savings validated after changes.

18. Mini Case Study — Upload Service Unit Cost

18.1 Initial situation

Evidence upload service costs rise 80% month over month.

Aggregate bill shows:

S3 + KMS + EC2 increased

18.2 Investigation

Unit cost reveals:

• object count increased 20%
• KMS requests increased 400%
• S3 PUT/HEAD increased due retry bug
• EC2 CPU low but network high
• noncurrent versions increasing because same key overwritten during retry

18.3 Fix

• idempotency key prevents duplicate upload
• immutable object key per content hash
• store S3 version ID once
• reduce HEAD polling
• multipart upload cleanup lifecycle
• KMS bucket key evaluated
• EC2 instance family changed for network profile

18.4 Invariant

Cost spike was a correctness/retry bug, not just a finance issue.

19. Mini Case Study — ML Training Spot Economics

19.1 Workload

GPU training job uses Spot for all nodes.

Spot price is much lower, but jobs restart from scratch on interruption.

19.2 Actual cost

low hourly cost
high failed-attempt cost
low success rate
long wall-clock time

19.3 Improved design

• On-Demand baseline coordinator
• Spot workers diversified across pools
• checkpoints every N minutes to S3/FSx persistent
• resume from last checkpoint
• max interruption budget
• cost per successful model dashboard
• Capacity Blocks/Reservations evaluated for critical campaigns

19.4 Invariant

Spot optimization is measured by cost per successful job, not hourly discount.

20. Summary

Compute and storage cost engineering is architecture work.

Key principles:

1. Build unit economics.
2. Allocate cost by owner/service/data role.
3. Use Cost Explorer for quick analysis.
4. Use CUR/Data Exports for detailed modeling.
5. Use Compute Optimizer for rightsizing signals.
6. Use Savings Plans/RI for stable baseline, not peaks.
7. Use Spot only for interruption-tolerant workloads.
8. Treat S3 versions, snapshots, backups, and idle file systems as first-class cost surfaces.
9. Optimize storage lifecycle without breaking recovery.
10. Use budgets and anomaly response as operational guardrails.
11. Validate savings against SLO/RPO/RTO.

The core rule:

Cost optimization is successful only when unit cost improves without weakening correctness, reliability, security, or recovery objectives.

Next, Part 074 goes deeper into capacity engineering: Service Quotas, EC2 Capacity Reservations, Capacity Blocks, fleet diversification, storage capacity forecasting, quota automation, and capacity game days.

References

• AWS Cost Management User Guide — Optimizing cost with rightsizing recommendations: https://docs.aws.amazon.com/cost-management/latest/userguide/ce-rightsizing.html
• AWS Compute Optimizer User Guide — What is AWS Compute Optimizer?: https://docs.aws.amazon.com/compute-optimizer/latest/ug/what-is-compute-optimizer.html
• AWS Compute Optimizer User Guide — Viewing resource recommendations: https://docs.aws.amazon.com/compute-optimizer/latest/ug/viewing-recommendations.html
• AWS Savings Plans User Guide — Compute Savings Plans and Reserved Instances: https://docs.aws.amazon.com/savingsplans/latest/userguide/sp-ris.html
• Amazon EC2 User Guide — Instance purchasing options: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-purchasing-options.html
• AWS Data Exports User Guide — What are AWS Cost and Usage Reports?: https://docs.aws.amazon.com/cur/latest/userguide/what-is-cur.html
• AWS Billing User Guide — Cost allocation tags: https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/cost-alloc-tags.html
• AWS Cost Management User Guide — AWS Budgets: https://docs.aws.amazon.com/cost-management/latest/userguide/budgets-managing-costs.html
• Amazon S3 User Guide — Using S3 Storage Lens to optimize storage costs: https://docs.aws.amazon.com/AmazonS3/latest/userguide/storage-lens-optimize-storage.html
• Amazon S3 User Guide — Abort incomplete multipart uploads: https://docs.aws.amazon.com/AmazonS3/latest/userguide/mpu-abort-incomplete-mpu-lifecycle-config.html