It is also possible to rotate your snapshots to keep their numbers under control - I wrote a perl script to do that for me. Given that snapshots are differential (in a way) and compressed, this approach is much more economical than using S3, as well as offering more options, it also allows you to restore data far faster, and should lock up your databases for a shorter period than generating a dump. The snapshot command only takes a (few) second(s) to return, after which you can unfreeze the file system - the snapshot created will be consistent, despite additional reads. If a deployment is lost, logs and Step Function executions in the AWS console will be irrecoverable. Have the following prepared: AWS Access & Secret keys. Once your file system is frozen (and your database flushed and locked if possible), take your snapshot (ideally, use the API directly, as opposed to the (very) slow Java based commands). When storing backups, WAL-G has numerous cloud storage provider options for us to choose from. The xfs_freeze, is still important to get a consistent snapshot though.
Then locally, some shell script to download the files to a folder that is mounted to the postgis folder. My understanding is that with PostgreSQL, people often simply take the snapshot (after freezing the file system) and rely on PostgreSQL's built-in recovery abilities to restore everything to a functioning state. The best workflow would be: There is an automatic daily binary backup stored in AWS S3. Amazon's Linux/CentOS) without much issue). However, you will not be charged for the I/Os you consume. With Provisioned IOPS (SSD) storage, you will be charged for the throughput and storage you provision.
Note that maximum realized IOPS will vary by database workload. There is a great script that will do this, as well as freezing your filesystem (if xfs) called ec2-consistent-snapshot (the site does have some comments on PostgreSQL that may point in your an acceptable direction - it is designed for Ubuntu, but, works on other distributions (e.g. You can provision and scale from 1,000 IOPS to 80,000 IOPS and 100 GiB to 64 TiB of storage with the PostgreSQL DB Engine. To begin the snapshotting process, you want to freeze your databases, and flush your tables. I favour using XFS as the filesystem since the entire filesystem can easily be frozen. The first requirement, of course, is that your databases are stored on an EBS volume so that they can be snapshotted. I can't speak for PostgreSQL as I don't use it, but I use a variation on your option 1 for backing up MySQL databases on EC2, and have successfully restored them, without issue.