Database/server structure

Thanks 'iwasa'. That's helpful. Would an option be to host the MongoDB database remotely (e.g MongoDB Atlas) and point the site to it from the EC2 server, or best practice to have two very separate EC2 instances ?

Hi.

You can host.
Multiple websites can coexist by using functions such as virtual domain and port binding provided in the web server (IIS / Apache / Nginx ...).
Also, MySQL and MongoDB are databases with different characteristics, so it is common to use them together. (It's not MariaDB, right?)

However, you share resources across multiple websites.
Understand that if one site experiences performance (heavy load), bugs, or other issues, the other site may be affected.
And some life cycles such as taking and restoring snapshots are also shared.
Also, there is an upper limit for scale-up and no upper limit for scale-out.
Therefore, it is generally recommended to distribute the servers.
It is recommended to use multiple EC2 instances designed with smaller and more appropriate sizing.

If the workload has characteristics that can ignore the above disadvantages, there is a cost advantage if it is packed in one server.

It's a trade-off.

If you expect to have growing traffic to your websites and need to scale up your services in time, it is highly recommended to architect your services correctly in advance. The main advice is to split your compute from your databases. It will allow you to have multiple compute instances (behind a load balancer) that will all access the same databases, and at the same time, you have your databases replicated across multiple instances for redundancy and scale.

It is also recommended to use managed services for your databases such as RDS (for MySQL, for example) or Document DB, or Atlas (for Mongo DB, for example). These managed services are taking a lot of the heavy lifting such as backup, scale-up, automatic recovery, etc.

Even if it might be easier for your developer to develop everything on his laptop and deploy everything to the same instance in a similar way, in the longer run (if you believe that your service will grow), you will "hit the wall" in the most crucial time of your success. If you then experience downtime of your service, you will lose many of your potential customers, until you rearchitect your services for scale. Therefore, I advise you to do it earlier and now.