aws pricing is literally a catalog. what and how much you buy is kind of the whole thing. a subset of the catalog is good.
aws core primitives are:
- flexible
- reliable
- robust
if your service succeeds, you will definitely want to move some components out of aws, but not all of it. aws can always remain the control plane.
if you don’t need what aws offers, don’t use it. they offer it at a price, and it is what it is. thanks to other providers, it likely will remain fair over time.
what i outlined was how to make aws cheap(er). it’s a simple strategy:
- use the primitives: s3, ec2, nvme, route53, lambda, apigateway
- avoid the services: rds and all the rest
- avoid heavy egress: use cloudflare workers and r2
scaling to zero means avoiding things like kms keys.
not sure where you got apigateway pricing from, it definitely scales to zero without fixed minimum cost.
lambda will always be the most reliable part of your stack. when you have enough traffic that it’s worth it, use ec2 instead and let lambda manage those machines.
I don't agree about avoiding the services. If you're mega successful down the line you can likely afford to do the migration when it's expensive, but the services are what save you_time_, and initially money too. I can spin up an RDS server that is secure and production ready in less than 5 minutes that quite frankly I don't need to touch for a very very long time. If we need more power, I can restart the instance with a bigger type, or if we've overspecced I can use a smaller one. Compared to running your own instances on ec2 there's a few hours of poking around to do things like password handling, backups, logs, not to mention you're now responsible for managing updates and the likes. It's a false economy to avoid them IMO.
That's not to say you should immediately pivot to all in AWS all the time but like any engineering be aware of the price you're paying to build Vs buy
> if your service succeeds, you will definitely want to move some components out of aws, but not all of it. aws can always remain the control plane.
Do you factor in the costs of dev time in a cross cloud environment at all? Nevermind all the AWS specific tooling and code you write, which needs to be thrown away and re-done to accomplish this?
Don't get me wrong, I love AWS when I'm not paying the bill, it makes my job of shipping features quickly so much easier. It's good and it works well. But it's a little crazy to think it's "cheap" and to ignore the costs of vendor lock in.
Do you factor programming language and library and operating system and cpu architecture into your vendor locking and specific tooling you need to write?
vendor lockin is fine. it’s like having a great employee, but not leveraging them fully because bus factor and cogs. you should be sad if a great employee leaves, or your vendor shuts down. choose both carefully, and trust them.
my only experience expanding out of aws is to cloudflare for egress. i’m sure it can be rough, but so can anything solved with dev time.
expanding out of aws with individual tightly scoped components should be easier than general cloud migration. just bandwidth egress. just cheaper cpus for background processing. just whatever.
keep the complicated stuff on main cloud where it belongs.
aws core primitives are:
- flexible
- reliable
- robust
if your service succeeds, you will definitely want to move some components out of aws, but not all of it. aws can always remain the control plane.
if you don’t need what aws offers, don’t use it. they offer it at a price, and it is what it is. thanks to other providers, it likely will remain fair over time.
what i outlined was how to make aws cheap(er). it’s a simple strategy:
- use the primitives: s3, ec2, nvme, route53, lambda, apigateway
- avoid the services: rds and all the rest
- avoid heavy egress: use cloudflare workers and r2
scaling to zero means avoiding things like kms keys.
not sure where you got apigateway pricing from, it definitely scales to zero without fixed minimum cost.
lambda will always be the most reliable part of your stack. when you have enough traffic that it’s worth it, use ec2 instead and let lambda manage those machines.