Mavatoo

I know this topic is a little aged but I thought I would throw in my two cents as well since I have succeeded in setting up a server on AWS. Here are a few tips for anyone who wants to give it a go (btw - everything I have done so far is on the 3.3.5 branch): As others have stated, you can't just stand up a micro EC2 instance on its own. There just isn't enough RAM by default on those instances. Two options that have been mentioned in this thread already are: mounting a swap drive and separating the DB from the world server (i.e. running on two servers). 1) Extra swap might be fine but that solution pretty much guarantees poor performance since disks are much slower than RAM. Fine if you are just testing a few things out but not great for a long term solution. 2) If you are planning to run it short-term (i.e. less than a year), then you can run the server within the AWS free tier by setting up the DB on a separate EC2 instance form the world server. After your account is active for a year you get bumped out of the free tier and Amazon will start charging you. Note, I have not tried this option myself - just guessing that's what CDawg did to get around the memory issue on a single instance. Although there are advantages to separating the two (cost being one of them), the world server process actually seems to use much more resources than the MySQL database, so you will still end up choking your world server. I have found the best performing solution for the money (on AWS) so far is to run an EC2 small instance. In this scenario MySQL typically uses about about 11% of the 2GB of RAM and the world process uses about 66%. The auth process is negligible. Unfortunately EC2 small is not available in the free tier, but if you get a reserved instance, the cost works out to just over $12 / month... which isn't horrible if you are splitting the cost with some other buddies who feel up to messing with a trinitycore server. For those who are less familiar with AWS, here are a couple of other tips: Get familiar with and use the AWS security groups to limit which IP ranges can access it. This is a good way to 1) make sure you don't have random hackers attempting to access your server; and 2) it keeps it "private" such nobody will stumble across it since they can't access the ports. If you access it from an IP address that is dynamic, you can usually look up your ISP's network range and use that instead of a single IP address. Get familiar with the cron, AWS CLI, S3, and mysqldump, and use the combo to push database backups into a private S3 bucket. The cost will be very small (my list bill was $0.01 for the month), and if you set up your S3 bucket to keep previous versions it will give you a helpful and extremely cheap daily backup. The best AMI to use as of July, 2017 is the standard AWS Ubuntu 16.04. It is currently fully supported by trinitycore and you won't have to mess with the apt sources or anything. Remember if you have a local machine with a lot of power, you can use virtual box or vmware to stand up an equivalent operating system on your local machine to compile, then rsync the binaries over to your server. This can save you a lot of time, plus you end up using up less disk space due to compile artifacts on your server. Always take a snapshot of your EC2 instance before you upgrade anything. That way if your upgrade goes sideways you can easily roll right back to where you were. Delete old snapshots once you are sure you won't need them, since you pay for the storage. I hope this helps!