Most "save money on AWS" guides only cover EC2. RDS, S3, Lambda and data transfer discount differently — and are often the bigger line items.
Search for "how to save money on AWS" and you will find the same three things: Reserved Instances, Savings Plans, Spot. They work — but they are all discounts on EC2 and its compute cousins.
The problem: EC2 is often not your largest line item. Databases (RDS), object storage (S3) and data transfer frequently cost more — and they price completely differently. Applying EC2 tactics to them achieves nothing.
This page goes service by service, and for each one gives a decision rule and a concrete action — not a list of discount names. (All five providers side by side, where the mechanism differences read more clearly, are in cloud discount mechanisms compared.)
Why every "save money on AWS" guide is about EC2
Because EC2 is the entry point and the most widely used service. Writers assume you run EC2, and EC2 happens to have the cleanest discount model: commitment in exchange for price, with three options matching three levels of certainty.
Real bills do not look like that. A typical mid-sized workload breaks down roughly as:
| Service | Typical share | How it discounts |
|---|---|---|
| EC2 compute | 30–50% | Reserved Instances / Savings Plans / Spot — commitment for price |
| RDS databases | 15–35% | Reserved Instances (commitment for price); engine and family decide the room |
| S3 and storage | 5–20% | Not a discount — a matter of tier and lifecycle choice |
| Data transfer | 5–25% | Structural (architecture, caching); there is almost no discount to buy |
| Everything else (Lambda, SQS, monitoring…) | 5–15% | Partly covered by Compute Savings Plans |
The point in one line: EC2 is "buy commitment", S3 is "pick a tier", data transfer is "change the architecture". Three completely different methods — bundling them into one conversation is the biggest misleading habit in this topic.
If you have already done one round of EC2-style optimisation (for example the six moves in our AWS bill optimisation guide), these four are what remains.
RDS: commitment discounts that are easier to get wrong
RDS supports Reserved Instances with the same shape as EC2: commit for one or three years for a discount off on-demand, deeper with more upfront payment. But the cost of getting it wrong is higher than on EC2, for two reasons.
First, database sizing changes less often. Applications scale up and down freely; databases involve data migration, so they tend to be locked down hard. That sounds like predictability — but it also means a wrong size is carried for the whole year.
Second, an RDS reservation is tied to instance family + region + engine. Commit to db.m5 MySQL in one region and you are not covered if you: move to db.m6g (Graviton), change engine, or move region. All three constraints are tighter than EC2 Reserved Instances.
The most common mistake: committing to today's largest instance to capture the discount. But database pressure usually comes from specific windows (batch jobs, month-end settlement) — peak is not normal. Commit against p95 or average utilisation, not peak.
The decision rule: look at enough history in the RDS console to cover a full business cycle, and compare normal utilisation against peak. If the gap is wide, your next move is downsizing or read replicas — not a commitment.
S3: not a discount — putting objects on the right tier
S3 has no commitment-for-discount model. Around 99% of S3 savings come from tier choice and lifecycle rules, not from any discount.
The pricing logic is: the less frequently you access it, the slower the retrieval, the lower the durability — the cheaper it gets. So the real question is: how often is the data you store actually touched?
- Accessed regularly: leave it in standard storage. Pushing it to a colder tier costs more because of retrieval charges.
- Touched a few times a month: an infrequent-access tier usually saves money, at the cost of a minimum storage duration.
- Kept but essentially never read: archive tiers are far cheaper per GB, but retrieval takes minutes to hours and is charged separately.
- No appetite for classification: S3 Intelligent-Tiering moves objects between tiers based on observed access, removing the need for manual rules. Good when access patterns are unpredictable and nobody wants to maintain policies.
Concrete action: open Storage Class Analysis or access logs and look at the actual access distribution — do not classify by intuition. Many teams pay standard-tier rates for years on data they labelled "important" but never read.
Two more items that get overlooked: versioning and incomplete multipart uploads. In a versioned bucket, deletes do not free space; and interrupted multipart uploads keep billing for the parts already stored. Lifecycle rules that expire non-current versions and abort incomplete uploads usually produce an immediate, visible reduction.
The full method — including minimum storage durations and retrieval fees per tier — is on the S3 storage class guide page.
Lambda and Fargate: serverless still earns commitments
A common assumption is that serverless has nothing to discount — you pay per invocation, so you pay for what you use. That is only half right.
AWS Compute Savings Plans cover not only EC2 instances but also Lambda and Fargate. You commit to an hourly compute spend, and AWS offsets your compute usage at the discounted rate — whether that usage comes from EC2, Lambda or Fargate.
That means two things:
- If your Lambda usage is steady — fixed scheduled jobs, stable API traffic — it can be covered by a Compute Savings Plan and earn a discount.
- More usefully, the reverse: because Compute Savings Plans do not lock instance shapes, they suit a mixed estate of some EC2, some Fargate and some Lambda. One commitment covering three compute types is far harder to get wrong than three separate commitments.
Decision rule: look at whether Lambda and Fargate spend is stable across recent months. If it swings widely (only batch jobs during promotions), do not commit to it. If there is a steady floor — a fixed daily workload — that floor can go into the commitment. Commit only the baseline; leave elasticity on demand.
The difference between Compute and Instance Savings Plans, and how they interact with Reserved Instances, is on the Savings Plans and Reserved Instances guide.
Data transfer: the line item everyone skips
Data transfer out is the most consistently underestimated item on an AWS bill, for a simple reason: there is no discount to buy. No reservation, no commitment plan — only architectural reduction.
The model in broad terms: inbound is usually free, outbound is charged per GB; traffic across availability zones carries a small charge; cross-region is more expensive again. So the cost usually shows up here:
- Serving large volumes from object storage straight to the internet — images, video, installers. This is the most common source.
- Chatty cross-AZ communication: without topology awareness, inter-service calls across zones add linearly with traffic.
- Cross-region backup and replication: a thorough disaster-recovery design keeps paying for its own replication every month.
- NAT gateway data processing charges: people watch the instance hours and miss the per-GB component.
Concrete actions (no shortcut to buy here — only three structural moves):
- Cache what can be cached. Hand static assets to a CDN so repeated requests do not repeatedly hit the origin. This is usually the single largest line.
- Make cross-AZ calls local-first. Have services prefer dependencies in the same availability zone, with cross-zone as fallback only.
- Co-locate what talks a lot. If two services exchange heavy traffic, putting them in the same region — or the same AZ — beats optimising the code.
Why it is so easy to miss: EC2 and RDS are "visible big blocks"; data transfer is "many small blocks that add up". And because it is usage-based, if you do not actively reduce it, it grows with the business on its own.
Using all three kinds of saving together
Taken together, AWS cost optimisation is three fundamentally different problems:
| Kind | Services | Method | Key action |
|---|---|---|---|
| Commitment for price | EC2, RDS, Lambda, Fargate | Reserved Instances / Savings Plans | Commit the baseline, never the peak; prefer Compute plans for mixed estates |
| Sizing for price | S3 and other storage | Tier + lifecycle rules | Classify from access data, not intuition; expire old versions and incomplete uploads |
| Architecture for price | Data transfer, NAT, cross-region | Caching / topology / locality | No discount exists — change the design; start with CDN and same-AZ preference |
Order matters: do "architecture" and "sizing" first — they need no commitment, can be done any time, and carry no risk. Then do "commitment", which locks you in for a year. Many teams do it backwards: buy Reserved Instances to capture a discount, get the size wrong, and carry it for twelve months.
One more layer worth knowing about: everything above is an official discount — AWS giving you a better rate. There is also the route of provisioning and settling through a reseller, which lowers the amount you actually pay. It does not conflict with Reserved Instances or Savings Plans; the two stack. That logic is on the AWS discounts and reseller pricing page.
Do not miss the layering: a reseller discount applies to what you pay the reseller; an official discount applies to the unit price on your AWS bill. Different layers, so both apply at once — it is not either/or.
Common questions
For RDS, should I buy Reserved Instances or use Savings Plans?
If the instance family and region are fixed for a year, Reserved Instances discount more deeply. But remember the RDS reservation is bound to family + region + engine — change any one and the commitment is wasted. If a move to Graviton or an engine change is plausible, do not lock in long-term; commit a shorter term while you watch.
Is S3 Intelligent-Tiering worth enabling?
It depends on whether access patterns are predictable. With clear hot/cold separation (for example logs nobody reads after three months), hand-written lifecycle rules usually save more because you control the boundaries exactly. If patterns are irregular and nobody maintains the rules, Intelligent-Tiering is safe and low-effort — it carries a small monitoring and automation charge, which only matters at very large volumes.
Is there really no discount for data transfer?
Nothing in the commitment-for-discount sense. But two indirect directions exist: move outbound traffic behind a CDN, where origin fetch is usually cheaper per GB; and note that traffic between some services under specific conditions is not charged (for example within a region over private networking for certain services). Both need to be assessed against your actual architecture — there is no universal answer.
How do I decide whether Lambda usage justifies a commitment?
Look at the floor, not the total. Chart the last three months of Lambda spend by day and find the part that occurs every single day — that is what can be committed. Jobs that only run on certain dates (month-end settlement, scheduled reports) should stay on demand.
Which of these should I do first?
In order of "requires no commitment": clean up idle resources and unattached volumes → review S3 tiering and lifecycle → then look at data transfer architecture. None of those three require you to promise anything; they can be done immediately and carry no risk. Once the bill structure is clear, buy Reserved Instances and Savings Plans — by then you will know how much to commit.