Aurora I/O optimized config saved 90% DB cost

Vendor lock-in. It prevents people from otherwise picking the best provider for the task at hand - for example using some managed AWS services, but keeping the bulk of your compute on-prem or at a (much cheaper) bare-metal host.

It makes sense, but I wish there was an option to opt-out, as to allow high-bandwidth applications that are fully on AWS (at the moment AWS is a non-starter for many of those even if you have no intention of using AWS competitors like in the scenario above).

Maybe they should just price end-user egress vs competitor egress differently (datacenter and business provider IPs are priced like now, but consumer-grade provider IPs are much cheaper/free)? That would discourage provider-hopping, while making AWS a viable provider even for high-bandwidth applications such as serving or proxying media.

Maybe it's just a goal to reduce costs, but it seems likely that this is a response to Google's introduction of AlloyDB, a Postgres-compatible database competing with Aurora that is advertised as having "no...opaque I/O charges". I doubt Amazon was feeling generous.

Agreed.

Azure on the other hand is notoriously expensive and do everything possible to raise prices.

And then tie in how some AWS services only a binary choice between logging ridiculous volumes of data or nothing at all (looking at you, AppSync) to make the log ingestion fees high too.

I have a hard time reading "amazon" and "lower costs" in the same sentence.

The cloud is consistently an order of magnitude more expensive than self hosting, even when including people cost, unless you need every single bit of load balancing/high availability/normalization they provide.

The vast majority of projects don't.

Sounds like good material for a technical blog post.

FWIW, I'm actively exploring native partitions on Aurora with Postgres and I'm seeing very little benefit. Two identical tables, each with 500M+ rows, and I'm not seeing any meaningful performance/IO changes. A composite index with the partition key as the first entry has been as effective for reducing IO and query time as partition pruning. I'm sure there are workloads where partitioning makes more sense, but I've been surprised by how little difference there was in this case.

Outside of that though, you can go to your AWS billing, filter on RDS, and slice by usage type. They make you dig, which is why I pref Datadog

Disclaimer: I work for Vantage.

PS. I maintain https://ec2instances.info/rds and recently added support for Aurora I/O Optimized pricing.

This always comes down to opportunity cost and staffing. If their team doesn’t include Postgres or MySQL experts, or security experts, etc. outsourcing that to AWS allows them to spend their staff budget on things they cannot outsource.

One thing to remember is that your organization can only do so many things a year. That number varies based on complexity, internal overhead, customer and regulatory overhead, etc. but it’s finite and lower than you think. If you’re spending time on MySQL patching or trying to figure out how to patch your servers, that’s taking decisions away from your product. That can still be the right call but one thing I’ve noticed over the years is that many people are prone to dramatically underestimating that cost.