Why Usage-Based Pricing Is the Right Pricing Model for Cloud
Every cloud pricing model is a story about how the vendor wants you to behave. If you read the pricing page carefully, and I mean carefully, past the badges and the "starting at" asterisks, you can usually figure out which side of the relationship is supposed to lose. The model is the message. The unit of billing tells you what the vendor wants more of, and what the vendor is quietly hoping you'll forget to turn off.
I'm Angelo, a Solutions Engineer at Railway. Before this I spent years at Citrix, sitting across the table from places like Verizon and Lockheed, the kind of customers who read every line of a contract because their procurement org will not let them do otherwise. When you spend enough time inside those rooms you stop reading pricing pages as menus. You start reading them as legal documents that describe a behavioral hypothesis. Per-instance pricing assumes you will over-provision. Per-seat pricing assumes you will grow your team faster than your workload. Credit-based pricing assumes you will forget to top up. Each model has a customer it is built to reward and a customer it is built to extract from, and the vendor's margin lives in the gap between the two.
I want to make a specific argument here, and I'll say it up front so you can decide whether to keep reading: usage-based pricing is the only cloud pricing model where the vendor's incentives and the customer's incentives genuinely point in the same direction.
It has a real downside that I will not hand-wave away. But it is the only model that gets honest about what cloud actually is, which is a metered utility for compute, memory, storage, and bandwidth. Everything else is a story the vendor is telling itself about why you should keep paying when you're not using anything.
Strip away the marketing and there are roughly five shapes a cloud bill can take.
Per-instance pricing, the AWS EC2 shape, charges you for capacity reserved. You pay for the box whether the box is doing work or sitting at 4% CPU watching a cron job tick. The vendor's hypothesis is that you will overestimate your needs, lock in a reservation, and pay for headroom you will never touch. The vendor is usually right.
Per-seat pricing, the Datadog and GitHub Enterprise shape, charges you for each human who can log in. The vendor's hypothesis is that your team will grow. The model is uncorrelated with the work the platform does for you; it is correlated with how many badge readers your office has. The vendor wins when you hire, regardless of whether those hires generate any load on the platform.
Per-request pricing, the Lambda and Cloudflare Workers shape, charges per invocation or per million requests. It is closer to honest because requests are at least a proxy for work, but the unit is coarse: a request that runs for 30 milliseconds costs the same as one that runs for 30 seconds, and the pricing tends to flatter the easy cases while quietly punishing the long ones.
Credit-based pricing, the Vercel and Heroku-era shape, sells you a pre-paid bucket of "something" that maps loosely onto compute. You buy 1000 of a thing, you spend it, you re-up. The vendor's hypothesis is that you will buy more than you need, or that the credits will expire, or that you will forget what a credit actually is in physical terms and stop checking. Credit systems are designed to be slightly opaque, because opacity is the product.
Usage-based pricing, the Snowflake and Railway shape, charges you for measurable physical resources consumed: CPU-seconds, gigabyte-hours of memory, gigabytes of storage, gigabytes of egress. The unit is a thing that exists in the universe. When you stop using it, the meter stops. The vendor's hypothesis is that you will use more of it because your workload will grow, not because the vendor has tricked you.
The question to ask of any of these is the same: which customer behavior makes the vendor money, and is that the behavior you actually want to be doing?
Per-instance pricing rewards over-provisioning. This is not a controversial claim; it is the explicit selling proposition of every cloud cost optimization tool in the market. The category exists because the pricing model creates the waste.
Here is how the trap closes. You provision a c6i.2xlarge because your peak load might hit 70% CPU someday. The instance costs the same at 4% CPU as it does at 70%. The rational move, once you've paid for the box, is to fill it. So you co-locate workloads on it, schedule batch jobs against the spare cycles, leave development environments running because turning them off doesn't save anything. Right-sizing becomes irrational, because right-sizing means giving back capacity you've already paid for. The pricing model has trained you to be wasteful, and the vendor's margin is built on the assumption that you will be.
The cloud cost optimization industry, FinOps as a discipline, exists almost entirely to compensate for this one design choice. There are conferences. There are certifications. There is an entire job function whose purpose is to undo the behavioral incentive that the pricing page created in the first place. Think about how strange that is for a moment. An entire profession exists to manage the gap between what you're billed and what you actually use, because the vendor's pricing model is designed to make that gap as large as possible.
Idle capacity is the per-instance vendor's profit center. They are not, structurally, on your side.
Per-seat pricing makes the platform a tax on hiring. Every engineer you onboard, regardless of whether they ship a single line of code that touches the platform, is another line on the invoice. The vendor's revenue is now coupled to your headcount, which is a thing you control imperfectly and reluctantly, and decoupled from the actual value the platform delivers, which is a thing the vendor should arguably be on the hook for.
The implications get weird fast. Read-only access becomes a budget conversation. Bringing a contractor in for a two-week engagement requires a procurement workflow. Junior engineers who would benefit most from observability access get put behind shared logins, which is exactly the wrong thing to be doing from a security posture standpoint. The pricing model has now made you slightly less safe in service of a vendor's revenue model.
And the deeper problem is that per-seat pricing assumes a static relationship between team size and platform load. It doesn't have one. A four-person team running a viral product can generate more platform work than a sixty-person enterprise team running a quarterly batch report. Charging per seat means the four-person team gets a discount on their actual consumption while the sixty-person team subsidizes them. That is not pricing alignment; that is cross-subsidy disguised as a fair model.
When the vendor wins by your team growing rather than your product succeeding, the vendor has misaligned itself with the thing you actually care about.
Usage-based pricing is the only model where the vendor makes more money when you are doing more work, and less money when you are doing less. That is a tautology when you say it out loud, but it is genuinely rare in cloud. Read the previous two sections again. Per-instance vendors make money when you over-provision. Per-seat vendors make money when you hire. Usage-based vendors make money when your application is busy, which is, if you think about it, the only thing you actually want a cloud platform to be making money on.
The alignment runs both directions. If your traffic doubles, the platform's revenue from you doubles, and the platform now has a real financial reason to make sure the next doubling is smooth. If your traffic goes to zero, because you shut down a feature or sunset a side project, the platform's revenue from you goes to zero, and that is correct. You should not be paying a cloud vendor for software you are not running. The fact that this needs to be argued for is itself an indictment of the industry.
The model also forces engineering discipline of the right kind. A slow query in a usage-based world costs you measurable money on the next bill. A memory leak shows up as a line item. Inefficient code is no longer a vague tech-debt complaint, it is a number you can point at in a meeting. Usage-based pricing turns performance work into a CFO-legible activity, which is something every platform team has been trying to do for fifteen years.
Now the downside, which I will not pretend is small. Usage-based pricing means your bill is variable. A viral weekend, a runaway loop, a misconfigured cron that wakes a sleeping service every second, any of these can grow your bill faster than you can react. This is real. The first time it happens to a hobbyist, they will be upset, and they will be right to be upset.
The answer is not to give up the model. The answer is spend alerts, hard limits, sensible defaults, and a dashboard that tells you what you are spending in close to real time. These are solvable problems and most usage-based platforms, Railway included, ship them as table stakes. The alternative is paying for capacity you aren't using and calling it "predictable." Predictability built on permanent overpayment isn't a feature; it is a tax you've agreed to pay on the assumption that your future self won't be able to manage a budget.
I want to be honest about the cases where this model is a worse fit. Three come up repeatedly.
The first is workloads with truly uncontrollable spikes. If you are running something where the traffic shape is determined by adversaries (think volumetric attacks, scraper waves, anything where the bill could be set by someone who is not you), usage-based exposes you to a class of risk that fixed pricing absorbs for you. Edge protection helps, rate limiting helps, but if you cannot meaningfully cap the upside of a bad day, a fixed model has a real argument.
The second is teams with finance functions that strongly prefer fixed budgets over variable spend. This is a process problem more than a technical one, but it is real. A 12-month committed-spend contract at a flat rate is easier to forecast than a meter, even if the meter is cheaper in aggregate. Some companies will choose certainty over efficiency, and that is a defensible choice.
The third is workloads that run at 24/7 full utilization. If you have a service that is genuinely pinned at 100% CPU around the clock, a reserved instance can be cheaper than the metered equivalent, because the vendor is willing to discount in exchange for a commitment. At the very top of the utilization curve, instance pricing wins on math. Most workloads are not there. The ones that are know who they are.
Pick the pricing model whose incentives match where you want to be in two years.
If you want to be the team whose traffic has grown ten times because the product worked, usage-based is the model where the vendor wins alongside you. The bill will grow, yes, because the workload grew. That is the trade you are making and it is the trade you want to make, because the alternative is paying the same bill while your product fails, which is not actually cheaper, it is just less obvious.
If you want to be the team that pays a flat number every month regardless of what happens, you can choose that. It is a real choice. But call it what it is: you are paying a premium for invoice stability, and you are paying it whether or not you use the thing. Do not let a vendor tell you that this is the "responsible" choice. It is a preference, and preferences cost money.
Railway prices on CPU, memory, storage, and bandwidth, the units that actually exist. Hobby is $5 a month with $5 of usage included, Pro is $20 per seat with usage on top of that. The seat component on Pro is honest: collaboration features have a real cost and we charge for them directly. The rest is metered against what your application physically does. When your traffic stops, the meter stops. When your traffic grows, so does the bill, and so does the work we are doing for you. That is the trade. We think it is the honest one.
Happy shipping.
Angelo
