Security, cost and GPUs
Where a cloud bill goes
The few categories that make up most of a cloud bill, a worked example that cuts $72k to about $43k, and the habit of reading the bill by service and tag.
A cloud bill looks like hundreds of small lines, but it groups into a handful of categories. Compute, databases, storage, data transfer and observability cover most of the spend. Read the bill by service, account and tag, then ask which category grew and why.
Concept
Data transfer (sometimes called egress) is the charge for data moving out of a cloud region, between zones, or through a managed gateway. Tags are key-value labels on resources, such as team=payments, that let you group costs.
The big idea
Most of the bill sits in a few places. Each place is driven by different things: hours and size for compute, instance class and storage for databases, volume and snapshots for storage, and gigabytes moved for transfer. Once you name the driver, you know which lever to pull.
| Category | Rough share | What drives it |
|---|---|---|
| Compute | 30 to 50% | Hours times size, and idle capacity |
| Managed databases and caches | 15 to 30% | Instance class, Multi-AZ, storage, IOPS |
| Storage | 10 to 20% | Volume, versioning, snapshots |
| Data transfer | 5 to 20% | Internet egress, NAT, cross-zone, cross-region |
| Observability and support | 5 to 15% | Log ingest, APM hosts, support percentage |
These shares are rough and vary by company. The point is to find your own top lines.
Walking through a worked bill
A mid-size SaaS company runs one primary region. Its month looks like this:
EC2 / node groups .............. $28,000 (steady API + workers)
RDS Multi-AZ ................... $12,000
ElastiCache .................... $ 4,500
S3 + snapshots ................. $ 5,000
NAT Gateways + processing ...... $ 6,500
ALB / data transfer ............ $ 3,500
CloudWatch Logs + APM .......... $ 7,500
Dev/staging always-on .......... $ 5,000
-----------------------------------------
Total .......................... $72,000Over one quarter, the team applies eight levers:
1. Rightsizing + ARM on API nodes -$6,000
2. Savings Plans on 70% of steady compute -$5,500
3. Spot for async workers (checkpointed) -$4,000
4. S3 lifecycle + delete orphan snapshots -$2,000
5. Gateway endpoints; cut NAT traffic 60% -$3,900
6. Zone-local Redis clients -$1,200
7. Log filter: drop debug in prod -$3,000
8. Staging scale-to-zero nights/weekends -$3,200
-----------------------------------------
Savings -$28,800
New run rate: $72,000 - $28,800 = $43,200Check the arithmetic: the eight levers add up to $28,800, and $72,000 minus that is $43,200. None of the savings required leaving the cloud.
Common mistakes
- Opening the invoice total instead of the breakdown. The total hides the driver.
- Assuming a storage spike is data. It is often forgotten snapshots.
- Assuming a networking spike is the app. It is often NAT or cross-zone traffic.
- Cutting Multi-AZ as waste. It is a reliability choice. Track it as one.
Check yourself
- Data transfer jumped this month. What do you check first? NAT gateways and cross-zone traffic, the usual suspects.
- Is a Multi-AZ database a waste line? Not automatically. It is a reliability choice, so track it as one and judge it against your availability target.
Key takeaways
- A bill is a handful of categories, each with its own drivers.
- Explore by service and tag, and name the driver before you cut.
- Waste (idle capacity, orphans, chatty traffic) is different from intentional cost (Multi-AZ, replicas for headroom).
Further learning
Next, see how to pay less for the same capacity in pricing models and commitments.
Related
Cloud cost and FinOps
Where cloud money goes, the levers that usually cut a bill, and how engineers own unit cost without waiting for a finance spreadsheet. Start here for the map of cost pages.
Cloud primitives on AWS and GCP
Regions, zones, compute, storage, managed databases and messaging, how the services map between AWS and GCP, and how to decide what to run yourself.
Linux performance analysis
The USE method and the 60-second checklist for finding why a box is slow, covering CPU, memory, disk, network and the container limits that look like application bugs.