While you are preparing the instance, you might just as well set up the SecurityGroup at the same time.

If you wish to save money on the project even further, consider if the system has to work 24/7 - maybe you have fixed working hours beyond which you can set up the maintenance window for updates/patching and then shut down the system overnight? Consider using Lambda functions for start/stop GitHub I would say that t2.small is a good compromise, t2.medium should be plenty, unless you have dozens of users working at the same time. In my case, t2.micro was sufficient during development, but even then, machine was left with 60MB of available RAM, so 2GB of RAM is absolute minimum if you have more than one user working on it (it will work with 1GB RAM + a bit of swap, but it will be horribly slow in regenerating graphs). RDS in my specific case could be of benefit (as mentioned I have my own 'data source' that needs to be queried), but in usual situations - you will be querying other RDS systems ANYWAY.ĭeploy an instance in the desired region. But if you insist - RDS works just fine, MySQL/MariaDB and PostgreSQL, that's how I started, before I realized I'm burning cash. MySQL server installed on the instance itself, not as RDS.

Having the above in mind, the project comprise of: The only solution is to start over or (if you are smart enough to have EBS snapshots every night :) ) to revert back the whole system. Yes, H2 has 100% failure rate in my experience.

forceful kill of a process by kill -9 pid of the app (jar) while it’s doing any updates to the tables WILL corrupt the data, and to my experience so far, NONE of the available tutorials work. DO NOT use the default H2 backbone for production. And the developers of Metabase will agree with me - repeatedly, all over the place. H2 is not fit for any production purpose. One thing that absolutely needs to happen is - the backbone database (which metabase uses to store user accounts, system settings, ‘questions’, graphs settings and so on) need to be moved away from the default file-based h2 format to a real database. If you insist of having a fancy infra, follow Metabase’s own tutorial Metabase on ElasticBeanstalk (which at the time of writing this tutorial, didn’t actually worked for me). properly set up AWS Backup!) and coffee, not on infastructure that serves no purpose other than some imaginary brownie points. Spend your money on keeping regular snapshots, AMIs (e.g. Need this to be portable/redeployable? Just make an AMI after initial deployment (before any data sources are added to metabase), share it with regions/accounts you wish, deploy there (remember to chage the passwords :) ) - happy days. Metabase database is tiny (less than 10MB?) my source of information - a single table with tens of thousands of rows - 20MB (in reality you will query other database sources that exist for their own purpose so your needs will be even smaller!) - why would I create a separate RDS (or two!) for that? With snapshots? Multi-AZ? Why would I bother with ElasticBeanstalk, and cloudforming it? The ONLY benefit is that Jeff has more money to pay his alimony (and for his space trips). So as much as it’s fun to deploy complicated infrastructure, it only benefits Amazon. With dozens of users working simultaneously. I started this project with ‘best practices as understood by Amazon’ in mind - decoupled, scalable, fault resistant… And then realized, that I know a few really heavy production systems that don’t have any of that and… function very well. Metabase on Amazon Linux 2 This tutorial covers deployment steps of Metabase system using Amazon Linux 2.

Metabase tutorial