restic backup it’s already integrated into my playbook:
well. someone has to write a restore script. in case of a total server loss. if you have to restore a file deleted by a user that would be manually restored.
so. the playbook - together with some cloud-init magic and a yet to be written restore script - would give you a quick “bare-metal-restore”. 10-20min you would be up again.
if you consider aws as your cloud provider and you want to have a restore automated in case of failure: put your data, database and nextcloud app on an efs share. (might be a performance killer for the database. depends on the files access frequency.) run the ec2 server in an autostart group. you have to create a “nextcloud ready” ami. that is to say a boot image that has nginx, redis and postgres installed and would mount the efs share at launch time. the aws autoscaling mechanism would kill and recreate the ec2 in case port 443 is longer answering. and will send you an email if that happened.
that is similar to the idea of container. you put your data on a reliable, persistent storage (efs) and your app on immutable hardware (ec2). if anything happens to nextcloud (or the server) it will be recreated automatically.
nextlevel: you use rds (aws database service) for the postgresdb and elasticache (for redis). on the ec2 you would have only nginx and nextcloud app.
(not sure because I didn’t test it yet. in this scenario you could add as well a load balancer and more than one ec2. but that wouldn’t be in your budget anymore.)
you can estimate your costs here: Amazon Web Services Simple Monthly Calculator or here: https://www.ec2instances.info/
since you considered docker and kubernetes: docker wouldn’t do the trick. if the server fails, docker is dead also. kubernetes is - imho - far too much for your purpose. it would only make sense of you have more than one client.