It could be that we work in pretty different problem spaces, but I've almost never seen database backups be a significant cost in cloud computing. Generally storage is very cheap compared to compute, and that's especially true for things like DB backups where -- since they almost never get accessed, and since even when they are accessed latency is typically a non-issue -- AWS and GCP can put them on literal tape decks and store them for pennies per GB.

Database servers that need really high concurrency and low latency can be pricey, though, especially if you do the typical start-up thing and use something super "general purpose" like Redis that in theory is very well optimized but, because it happens to not fit your specific use-case very well, is awful in practice. Redis is excellent at being a cache for web requests, but if you try and use it as some kind of pseudo-CDN for boatloads of data you will have a very bad and very expensive time.

Where I usually see people run into trouble, though, is just basic compute/server costs. It can happen in a bunch of ways -- most obviously, Python is much slower than most compiled and non-GCed languages. If whatever you're doing isn't time sensitive, that probably doesn't matter, but if you need a lot of concurrency/throughput that's going to translate into way more instances (or more CPUs per instance). If I'm processing ~1k documents per hour (let's say 0.3 per second), and Python takes 100 seconds per document, you need 30 instances to keep up. If, say, Rust could do the same thing 30x faster (which is a pretty average speedup from Python->Rust in my experience), then you only need one. As a side note, the global interpreter lock in Python can make this way worse, if you don't know about it. If you're CPU-bound but the problem is amenable to parallel processing, you have to know that python multi-threading does not use multiple cores unless you go out of your way to use multiprocessing (which is often a pain in the ass).

Memory usage can trip you up in ways you're not expecting, too. Python uses way more memory than most of the C-likes. If your workload is really variable, you want to use the smallest instance size you can pet job and horizontally scale the number of instances up and down as you get more/fewer jobs, so you don't have a bunch of compute sitting around costing money but not being used. It's pretty easy for that smallest instance size to be dictated by memory with python applications, but it's the CPUs that really cost the money in cloud computing, because they're what use the voltage. You might end up paying a lot more per instance with python, just because you need to have bigger instances with more memory and more cores, even though you don't actually need the cores.

My last job had both of those problems, and also, because the document processing time in Python was so slow and we were trying to get ingestion+processing time low enough for it to be used on an interactive webpage, people had started to look into GPU compute. GPU servers are usually horrifically expensive, and massive overkill during periods where you have some jobs but not many (so you can't scale them down below 1, even if you're using like 1% of its compute). So we were spending tons of money on servers, plus more money on GPU instances for testing and development, until we just wrote the damn thing in Rust, did away with the GPU instances, got rid of a bunch of database and cache instances that were basically just there to provide buffer storage for when we had a ton of requests all at once (and also ended up needing to spend less money on load balancing and autoscaling) and our monthly bill went from ~90k to ~20k.

This isn't to say that you should never use Python in the cloud -- I'm actually quite fond of it for the sorts of things that you can solve with AWS Lambda. Also, it can be optimized way more than most people think. You can use really highly optimized third-party libraries for things that are performance bottlenecks (numpy is famously written in c for this exact reason), and you can also look at things like Cython. If you're a small startup that doesn't have the time to put into optimization, though, and you're spending money on compute at any kind of actual scale, imo Python is almost certainly not the right choice.