On AWS, database server means RDS. That's great because you can manage snapshots and replicas at last protection from your data. RDS is very stable, and all the maintenance is easily managed. With monitoring, you can evaluate when increase RDS instance (CPU, storage, ram).
For the license, I'm still trying to understand better. In a multi-node environment with Shared Persistence, you have only 1 repository with 1 License (in RDS). Logins and Tokens are managed from the central node using information ad session on the repository. I'm not 100% sure of this. For the extension of the license (for example: on standby servers), I wrote a post more specific in another thread; if you: have any information or more question, follow-up here:
In my cluster, I plan to use Auto-Scaling clusters for read-only apps. The instance type is the limit for the performance for the user: for heavy load, I could expect also to have 1 user for instance. I could consider also 2 classes for clusters:
Standard with m4.2xlarge, and Deluxe with m4.4xlarge. In the night and weekend should slow down to 1 instance running for clusters. This is just theory.
In my case, the dataset is not so big so I don't use all the RAM and CPU of m4.16xlarge.
For the Development, I'm using a separate server with a Test Site License. Developers works on a separate server with the last release of QS, attempted configurations, and when ready Apps are exported from Dev to Production. Dev Server is now a on-Demand m4.4x, but I will try on the weekend to move to Spot Requests (2 launches per day, only weekdays).
Extend Apps. I don't know exactly how it works on a Multi-Node Cluster. I will search; if you have something, please add to this post.
For disaster recovery (usually developers or sysadmin that mess up the cluster or should be an issue in the AWS zone), I usually keep AMI of the last released software in the same zone and in other zones. I will start manually the new node, and reconnect, reload manually RDS and EFS snapshots. This is the last resource that requires me awake and prompt and 1-2 hours to setting up everything.
Comment: my general perception is that Qlik Sense is relatively new (comparing to Qlik view), but often purchased from Qlik View clients, that are 'old school' clients working with on-premise data farms, not so much scaling, clustering. (expensive metal provided after weeks with high cost of maintenance and updating cycles of years). So not much versatility yet for AWS. Partners mostly don't have a clue on AWS and clouds (it's a new thing for most of them). I can count in the community probably a few dozens of Qlik Sense cloud active users. Comparing to thousands of QlikView, on-premises clients.
I also write a post on Windows Server platform: Qlik Non-Sense Windows Server.
This is a very forward-looking video and article - the indication was that the functionality shown wouldn't be something we'd see in the next release. I don't think there's anything to look at or test at this stage - it is an insight into what's going on in R&D...