Memory-optimised against general purpose: what a GB costs

Published 2026-11-01 · Prose last reviewed 2026-11-01 · Figures computed from the compute catalogue dated 2026-10-25

A FinOps guide by OptimNow · list prices from the static OptimToken compute catalogue

Every cloud sells a memory-optimised line at roughly twice the memory per vCPU of its general-purpose line, and a compute-optimised line at half. The question a database owner brings to the rate card is what the extra memory costs. The rate card gives two answers, and they differ by a factor of 3.2. The first is the average price of a GB on the instance, which is what a dollar-per-GB ranking reads. The second is the price of one more GB at the same vCPU count, which is what the decision pays. This guide reads the second off 5 rate cards.

How the price of a GB is read here

A step qualifies when two Linux rows come from the same cloud and the same generation of the same processor line. They carry the same vCPU count, and the upper row holds exactly twice the memory of the lower one. m5.large to r5.large is a step. m7i.large to r5.large is not, because it crosses two generations of Intel priced years apart. The difference in hourly price divided by the added gigabytes is the marginal GB. Accelerated and burstable rows stay out: a GPU sets the one rate and CPU credits set the other. The catalogue today yields 21 general-purpose to memory-optimised steps across 5 clouds (AWS, Alibaba, Azure, DigitalOcean and GCP), and 18 compute-optimised to general-purpose steps on AWS, Alibaba and DigitalOcean. OCI and OVH list one memory ratio per family in this catalogue, so no step can be read there. Both sides of a step come off one rate card in one region, so the regional multiplier cancels.

The step costs about a third, for twice the memory

Moving one rung up the ladder, from a general-purpose row to the memory-optimised row of the same generation and vCPU count, doubles the memory. It raises the hourly price by a median of 31.3% to 34.8%, depending on the cloud. Read per gigabyte, the added memory costs $2.19 to $3.08 a month on demand, Alibaba at the low end and GCP at the high end. The band is narrow: 5 rate cards, 13 processor lines between them, and the dearest marginal GB is 1.41x the cheapest.

What a vCPU costs, by the same reading

Take a row's price to be its vCPUs times a vCPU rate plus its gigabytes times a GB rate. The memory step then gives the GB rate, and the lower rung gives the vCPU rate. On that reading one vCPU-hour buys 8.8 GB-hours on AWS, 8.7 GB-hours on Alibaba, 8.7 GB-hours on Azure, 8.1 GB-hours on DigitalOcean and 7.5 GB-hours on GCP. Memory is the cheap component of the pair on every card measured.

The average tells the opposite story. Divide each row's hourly price by its memory and the memory-optimised rows read cheapest, a median of $5.17 per GB-month against $7.85 on general-purpose rows and $12.42 on compute-optimised ones. The vCPU cost is spread over more gigabytes, and nothing else changed. A dollar-per-GB ranking therefore puts the memory-optimised line first, and a dollar-per-vCPU ranking puts it last. Neither ranking prices the decision. The decision is a step, and a step costs $2.19 to $3.08 per GB-month.

One ladder, read whole

AWS lists all three rungs of one line at 2 vCPUs: c5.large, m5.large and r5.large.

Priced off the memory step, a 2 vCPU, 4 GB row on this line would list at $0.0810 an hour. c5.large lists at $0.0850, 4.9% above that line. The compute-optimised row charges for its cores: dropping half the memory from m5.large saves 11.5%, where doubling it costs 31.3%.

Against the line its other two rungs draw, the compute-optimised row sits at +4.9% on AWS, +4.8% on Alibaba and −19.7% on DigitalOcean on the clouds with a full ladder. On AWS and Alibaba the compute-optimised row carries a premium per core, so shedding memory saves less than the GB rate predicts. DigitalOcean is the counter-example: the compute-optimised row sits below the line, so there the compute-optimised line is the cheap line and the GB rate read off the memory step does not carry down to it.

Where the memory-optimised row saves money

A memory-bound workload that leaves its vCPUs idle has a second row to consider: the memory-optimised instance with the same memory and half the vCPUs. On the catalogue's matched pairs that swap takes 32.6% to 34.5% off the hourly price, by cloud, for the same gigabytes.

At 730 hours a month and a fleet of 20 instances, held for a year on demand:

The saving is a third of the bill for the same memory. A CPU chart cannot show it. OptimNow's practice library lists acting on CPU metrics alone, without reading memory, as the most common rightsizing mistake on AWS, where memory utilisation needs the CloudWatch agent before it exists at all. The swap above is what that metric buys. It saves nothing for a workload that uses its cores: that workload wants its vCPUs back at the next peak.

What this changes in a FinOps review

• Price the step, not the ratio. A request for a memory-optimised instance is a request for $2.19 to $3.08 per GB-month of extra memory at the same vCPU count. A dollar-per-GB column in a rightsizing report ranks the lines in the wrong order for that question.
• Read memory before touching vCPUs. A team at Crawl, with CPU utilisation and nothing else, cannot see the swap above. Installing the memory agent, or reading the engine's own buffer-pool metrics on a managed database, is what makes it visible. A team at Walk or Run reads the saving off the table and checks peak memory, not average, before resizing.
• Databases first. The working set of a transactional database is memory-bound by design, and the practice library sizes those on connection count and active sessions rather than on CPU. That is the population where a general-purpose row holding twice the needed vCPUs is most common.
• Commitments follow the family. A reserved instance scoped to m5 does not cover r5. A move up the ladder inside a size-flexible commitment is free; one across families is a new purchase, which the commitments guide prices.

The figures are US East on-demand list prices from the compute catalogue dated 2026-10-25, and they rebuild with it. They say what a cloud charges for a gigabyte, not the number of gigabytes a workload needs; that number comes from the workload's own metrics, and no rate card supplies it.

The FinOps reasoning behind this guide comes from OptimNow's open-source practice library: github.com/OptimNow/cloud-finops-skills. If you want your own fleet read against the memory and vCPU rates you are paying, OptimNow runs that review.

Data snapshot: 2026-10-25 · Compare all models · Cloud compute pricing · All guides