My AWS t2.micro instances are both in Northern California. They have extremely good uptime. In the two years I’ve been developing nderground, I have not seen any down time (which is remarkable). I run New Relic with nderground, which is a service that monitors nderground uptime and web performance, so I would know if the instances went off line.
I could have configured nderground so that it is supported in multiple regions, but this is not something I need right now. My motivation for using multiple instances with Elastic Beanstalk is that I want to be able to update my software without having nderground users experience down time. With multiple instances running at the same time, Elastic Beanstalk will update them sequentially (Elastic Beanstalk includes a load balancer).
Elastic Beanstalk will also spin up more instances as my load increases, but I have not seen this kind of load, except under artificial testing.
I believe that Elastic Beanstalk supports more web servers than Tomcat, so it may be possible to use other languages (Python, for example). I don’t know if you can run Elastic Beanstalk with the Apache web server.
As I wrote before, I don’t think that AWS has any competition right now. I want to do as little administration as possible. AWS offers several managed databases via their RDS service. I use RDS/Postgres for nderground.
The RDS databases just work. You spin it up and you don’t need to do anything else. Every once in awhile you get email telling you that they want to do a major software upgrade. You can choose the time for this or just let it happen.
For noSQL support I looked at a number of options. The first thing I looked at was MongoDB, since it is so popular. Then I read about what a pain it is to get MongoDB to scale. I also looked at Riak, which has better scaling. But Riak’s design was influenced by the original DynamoDB paper, so I just used DynamoDB.
DynamoDB just scales. Other than configuring resources for DynamoDB you don’t have to do anything — it will just scale to whatever size you need.
AWS is not without its downside. It has a huge learning curve and Amazon’s documentation is adequate, at best. The common pattern when you are trying to learn about their services is a front page that tells you that the service is the greatest thing since sliced bread. Then there’s the engineering documentation. Often there’s nothing in between to give you an overview of how to use the service.
In one case it was not until I had written software that I came to the conclusion that the service would not do what I needed it to do since the documentation was so weak.
I joke that AWS encourages good software design since you have to write tests first, just to determine if the software works the way you think it does. In almost all cases it has taken me several iterations to get the tests working properly, sometimes with the help of AWS support (I have a support subscription).
For more on nderground, see this Medium post.