Ask HN: AWS lambda pricing/lock-in concerns
We are building a data analysis app, and AWS lambda seems to offer a scalable, secure, and easily administrable engine for the computationally-intensive parts of the app.
The pricing structure is reasonable for now, but we are uneasy about becoming dependent and locked into lambda, should the pricing change dramatically in the future (this is Amazon, after all).
Is this a valid concern? And, if so, how can it be mitigated?
An open Ask HN community consultation from 2018 where @prmph convened hundreds of developers and bootstrappers to share real experiences, hard numbers, and tactics.
Core Principles for Independent Builders:
Participants share raw revenue figures, churn rates, and stack decisions that corporate PR never publishes.
Recurring answers reveal that distribution, not coding skill, is almost universally the rate-limiting step in developer businesses.
Practical recommendations on bookkeeping, payment gateways (Stripe vs Paddle), and freelance-to-product transitions.
Community Debate Themes:
Hundreds of active indie hackers contributed case studies, pricing heuristics, and pitfalls to avoid when moonlighting on side projects.
CATEGORY Ask HN Roundtables →
HISTORICAL ERA Cloud & Mobile Era (2014–2019)
COMMUNITY SCORE 4 points
TOTAL DISCUSSIONS 7 comments
Lambda seems like a pretty easy thing to change. The interface is just a single stateless function call, you could probably write a shim to any other system if it came to that. In general my feeling on lockin is I'd rather get the app done a month sooner, focus on my business at the small cost of being locked in.
If the concern includes leaving aws in general, data is a bigger issue. It's incredibly expensive to move data out of AWS, both in time(you probably have to make something distributed) and money. Also, if you choose one of the really native datastores like dynamodb, that could require a lot of code rewrite. But actually leaving, especially for price, is not something Ive heard many people do - often engineering time is worth so much more than servers its gotta be significant to make sense.
If you use node.js you can run on at least aws, gce and azure and have the benefit of
1. Cost saving because of zero cost for small usage each month
2. Ha if one provider is down reroute to the other
3. Reduces lock-in
Perhaps they will all eventually offer other languages as well, but at least it used to be node.js 6.x that was common on all three.
I track AWS pricing for a living. I’ve never yet seen a price for a released service increase; they have historically only gone down.
That said, the cost of the data itself is going to likely drive where you go. Porting functions to another provider is likely to be a challenge; each implementation has special unicorn warts to it.
Use an abstraction like Serverless so that you can easily switch to another provider.