Backups that are stored with the same provider are good, providing the provider is reliable as a whole.
(Currently going through the disaster recovery exercise of, "What if AWS decided they didn't like us and nuked our account from orbit.")
Well 2 commands...
aws rds export-task create \
--source-arn <SnapshotArn> \
--s3-bucket-name <Bucket> \
--iam-role-arn <Role>
aws s3 cp \
<S3 Location> \
<Local Dir> --recursive
But creating an S3 bucket, an IAM role and attaching policies isn't 30 commands.
There are also turnkeys solutions that allow one to spin up a DB, setup replication and backups inside or outside of big cñoud vendors. That is the point of db kubernetes operators for instance.
apt install automysqlbackup autopostgresqlbackup
Though if you have proper filesystem snapshots then they should always see your database as consistent, right? So you can even skip database tools and just learn to make and download snapshots.
Only if your database files are split across multiple file systems, which is atypical.
And again I'll emphasize proper snapshot, cutting off writes at an exact point in time. A normal file copy cannot safely back up an active database.
There's a question of whether you want to spend time learning AWS or spend time learning your DB's hand-rolled backup options (on top of the question of whether learning AWS's thing even absolves you of understanding your DB's internals anyways!)
I do think there's value in "just" doing a thing instead of relying on the wrapper. Whether that's easier or not is super context and experience dependent, though.