Cost Optimization

Pricing dimensions, cost tools and commitments, and the architecture choices that dominate the bill

Six dimensions, not one pricedata transfer surprises most often
Attribute, reduce, then commita Savings Plan before rightsizing locks in waste
Budgets alert, they do not capupdated up to three times a day
Architecture beats rate workmultiples, not tens of percent

1.AWS Pricing Dimensions

A service is not "expensive" or "cheap" — it bills on specific dimensions, and those dimensions are what an architecture is really choosing between. Compute is time × size. Storage is bytes × time. Requests are per operation. Provisioned capacity is paid whether used or not. Data transfer is per GB and depends on where the bytes go. Managed services add their own per-unit charge on top.

Key features

Compute is billed per unit of time at a size — so a smaller instance running constantly can cost more than a larger one finishing sooner
Storage is bytes × time, and old data costs the same per byte as new data unless a lifecycle policy moves it
Request-priced services (S3, DynamoDB on-demand, Lambda) scale cost with traffic rather than with capacity
Provisioned capacity (RDS instances, provisioned DynamoDB, provisioned concurrency) is paid whether or not it is used — idle is the expensive state
Data transfer pricing depends on direction and destination: out to the internet and across Regions are billed, and cross-AZ traffic within a Region is billed in both directions
Managed-service premiums pay for operational work, so the comparison is never just instance price — it is instance price plus the engineering time being replaced

Which dimension dominates, by service

Which dimension dominates, by service
Service	Primary dimension	The usual surprise
EC2 / Fargate	Compute time × size	Idle non-production capacity overnight and at weekends
S3	Storage + requests	Millions of small-object requests, and old data never tiered
DynamoDB (on-demand)	Requests	A scan where a query would have done
DynamoDB (provisioned)	Provisioned capacity	Provisioned for peak, used at average
RDS	Provisioned instance-hours + storage	A production-sized instance in every environment
NAT gateway	Hourly + per GB processed	S3 traffic routed through it instead of a gateway endpoint
CloudWatch Logs	Ingestion + storage	Debug logging left on in production

The dimensions, roughly in order of how often they surprise people

Data transfer

Cross-AZ, cross-Region, and NAT processing — invisible until the invoice

Provisioned capacity

Paid at 3am; idle costs the same as busy

Requests

Scales with traffic; a retry storm is a bill

Storage

Bytes × time; nothing ages out on its own

Compute

Time × size; the dimension everyone already watches

Signature

compute (time × size) · storage (bytes × time) · requests · provisioned (paid idle) · data transfer (per GB) · managed premium

Compute (time × size), storage (bytes × time), requests (per operation), provisioned capacity (paid idle), data transfer (per GB, direction matters), managed-service premium (buying operational work). An architecture chooses dimensions; the bill is the consequence.

2.Cost Tools, Tags, and Commitments

Cost work has two halves. Visibility: Cost Explorer for exploring, Cost and Usage Reports for the detailed record, and cost allocation tags for attributing spend to a team or a product. Reduction: rightsizing and cleanup remove waste, lifecycle policies move cold data down, and Savings Plans, Reserved Instances, and Spot exchange flexibility for a lower rate.

Key features

Cost allocation tags are what turn "the AWS bill" into per-team and per-product numbers, and they only apply from activation forward — historical spend is not retagged
Savings Plans and Reserved Instances trade a one- or three-year commitment for a lower rate; Spot trades interruption tolerance for a much lower rate
Rightsizing and idle-resource cleanup come first, because a commitment on over-provisioned capacity locks in the over-provisioning
Storage lifecycle policies move objects to colder classes on a schedule — the cheapest storage saving available and entirely mechanical
Cost and Usage Reports are the detailed, line-item record; Cost Explorer is the interactive view built for exploring rather than for reconciliation
Untagged resources are invisible to attribution, so a tagging policy enforced at creation is a prerequisite for any of this to work

The tools, and what each one is for

The tools, and what each one is for
Tool	Answers	Not for
Cost Explorer	Where is the money going, and how has that changed?	Line-item reconciliation
Cost and Usage Reports	Exactly which resource incurred which charge	Quick exploration
Cost allocation tags	Which team or product owns this spend?	Anything created before the tag existed
AWS Budgets	Alerting and acting when spend or usage crosses a threshold	Hard spending caps
Rightsizing recommendations	Which instances are over-provisioned	Workloads with spiky, bursty profiles
Savings Plans / RIs	A lower rate for committed usage	Capacity you might not still need in a year
Spot	A much lower rate for interruptible work	Anything that cannot tolerate a two-minute notice

Command

text

# Tag policy first — attribution is impossible retroactively
CostCenter   = platform | payments | data
Environment  = prod | staging | dev
Owner        = <team>
# Then activate them as cost allocation tags in Billing

Tag and attribute first, clean up and rightsize second, commit last — a Savings Plan bought before rightsizing locks in the waste. Budgets alert (updated up to three times a day, with billing delay on top); budget actions are what actually enforce. Non-production out of hours is the easiest large saving.

3.Architecture Choices Dominate Cost

Rate optimization — commitments, rightsizing — moves the bill by tens of percent. Architecture moves it by multiples. The same workload built with a gateway endpoint instead of NAT, or with zone-aware routing instead of random cross-AZ calls, can cost a fraction of the alternative while doing exactly the same work.

Key features

NAT gateway is billed hourly per gateway plus per GB processed, so routing S3 and DynamoDB traffic through it instead of a free gateway endpoint is pure waste
Cross-AZ traffic within a Region is billed, which makes a chatty service pair spread randomly across AZs an ongoing cost with no benefit over zone-aware routing
An over-provisioned database is the most common single large line: production-sized instances in staging and dev, and a production instance sized for a peak that never recurs
Excessive logging costs on ingestion first and storage second — production DEBUG output is usually the largest reducible logging cost
Idle compute in non-production is roughly three quarters wasted if it runs 24/7 for a team that works weekdays
Egress to the internet is billed per GB, so serving large static assets from an origin rather than a CDN pays twice — once in transfer, once in origin capacity

The six areas worth investigating first

The six areas worth investigating first
Area	What to look for	The fix
NAT gateways	S3 or DynamoDB traffic in the processing charge	Gateway endpoints; centralize the remaining NAT
Cross-AZ traffic	A large "data transfer" line with no owning service	Zone-aware routing, or co-locate chatty pairs
Internet egress	Large static assets served from the origin	CloudFront in front, with sensible cache headers
Databases	Production-sized instances in every environment	Size non-production for correctness, not for load
Logging	Ingestion GB far above what anyone reads	Turn off production DEBUG; route bulk logs to S3
Idle compute	Non-production running at 3am on a Sunday	Schedule it down outside working hours

Two levers, very different ceilings

Rate optimization

Savings Plans, Reserved Instances, Spot
Rightsizing and scheduling
Typically tens of percent
Fast to apply, easy to measure

Architecture optimization

Gateway endpoints instead of NAT
Zone-aware routing instead of random cross-AZ
CDN instead of origin egress
Can be multiples, and permanent

Signature

NAT + endpoints · cross-AZ traffic · internet egress · database sizing · log ingestion · idle non-production

Rate work moves the bill by tens of percent; architecture moves it by multiples. Check NAT and gateway endpoints, cross-AZ traffic, internet egress, database sizing across environments, production log levels, and idle non-production — and rank by waste, not by line size.

Spotted a mistake on this page? Tell us.

Read Sheet