IME, AWS is slower to set up initially. Since you are starting out with it, I'd say it will take longer to do things "the AWS way". This article should help quite a bit with that part.
The real trick with AWS, IMO, is figuring out what you want to do yourself vs what you want to have hosted. For example, they offer a hosted cache such as memcached or Redis. For my app, I run Redis myself as it required roughly 15 minutes of work total to set up and maintain in 2014. OTOH, that's not nearly the case with Postgres. I spent a day and a half tuning the version I host, switching to RDS, then switching back because RDS was too slow (even though by the specs, it was using a more powerful VM than the EC2 box I was running my instance on).
Basically, once you grok AWS, things become more productive AND you don't need to spend time on doing things like setting up VLAN's, transferring data between boxes, etc. You can do cool things like detach a virtual disk from one VM and attach it to another, rather than pushing 100 GB's of data over a network. This, AFAIK, is not something that Linode or Digital Ocean can do.
Having said that, DO is great for lots of things. It's a good place to experiment and to run lots of really small things. For me, that's side projects or things that I am trying out before thinking about moving them to the "big iron".
> Basically, once you grok AWS, things become more productive
> OTOH, that's not nearly the case with Postgres. I spent a day and a half tuning the version I host, switching to RDS, then switching back because RDS was too slow
These two statements are contradictory.
You would have been better off just renting a dedicated host for your DB and doing the tuning yourself (either in person or getting someone to do it) - because the AWS offering is slower than your own instance, and database is a service thats often ripe for easy optimisation by using a dedicated host/cluster of hosts vs virtualised host(s).
Of course dedicated hardware is faster. It is also very inflexible. You cannot clone your DB box to 10 more instances wishing minutes. You cannot detach and reattach volumes withing minutes. You cannot resize the box to 2x size withing minutes. You cannot move it to a different VLAN within minutes. AWS is not the speediest, but it certainly is flexible.
According to your comments though, you'd have been just as well served with a regular VPS at a regular VPS host - you wouldn't have wasted time to found out RDS is slow, and you wouldn't have issues with slower than usual disk IO on EBS.
My point about physical was just another common optimisation for performance critical DB servers, you could probably get close to bare metal speed with the flexibility of virtualised by using a "single VM on hardware" model that some providers offer now.
Thanks for the perspective. Right now I am still just in the experimental phase of building things and even an early beta is 6 months out for my project. Like you said there definitely are a bunch of useful tools on AWS. This article definitely convinced me to actually spin up an AWS instance and see how well it works before just going with Linode or DigitalOcean.
I don't think doing it the AWS way is always necessary from the start. You can do a lot of simpler stuff with ElasticBeanstalk or OpsWorks and you'll still be in a better position to scale than working straight on a VPS.
The real trick with AWS, IMO, is figuring out what you want to do yourself vs what you want to have hosted. For example, they offer a hosted cache such as memcached or Redis. For my app, I run Redis myself as it required roughly 15 minutes of work total to set up and maintain in 2014. OTOH, that's not nearly the case with Postgres. I spent a day and a half tuning the version I host, switching to RDS, then switching back because RDS was too slow (even though by the specs, it was using a more powerful VM than the EC2 box I was running my instance on).
Basically, once you grok AWS, things become more productive AND you don't need to spend time on doing things like setting up VLAN's, transferring data between boxes, etc. You can do cool things like detach a virtual disk from one VM and attach it to another, rather than pushing 100 GB's of data over a network. This, AFAIK, is not something that Linode or Digital Ocean can do.
Having said that, DO is great for lots of things. It's a good place to experiment and to run lots of really small things. For me, that's side projects or things that I am trying out before thinking about moving them to the "big iron".