Fuck you AWS for being so damn expensive.

Use the free time until it runs out, then switch

Why use AWS them?

Try digital ocean

Something I've been saying all along

I find EC2 to be way too expensive. Other AWS services are more affordable though, at least for us.

AWS ain't expensive, you're just comparing it to totally different services.
Try Rackspace first, the azure, the cloud engine, then say aws is expensive.

@dyedgreen I currently use digital ocean/vultr, was looking to make the switch to AWS for things like auto scaling, load balancing, cloud watch and elastic search, but fuck me after estimating mostly costs for ec2, s3, EBS and the above its ridiculously unaffordable unless your a company or enterprise.

@dfox yeah I completely agree with you. AWSs pricing seems to block out anyone but companies or enterprises.

@smithalan2 Like @dfox says, I think it depends on the services you use. If you use full blown VMs then things will definitely be more expensive. Most providers offer higher level app abstractions that aren't as expensive. They usually don't require the same configuration and management overhead of a VM, which is a plus! In Azure we use App Services to host APIs and Web Apps. Check out AWS Lambda if you haven't already. There's literally no server at all, they host your code and only bill you for compute time by the micrsosecond. It's insanely cheap and they even have a free tier!

@smithalan2 what is there that costs less than an ec2 t2.nano? I've not found anything other than the big 4 that has the features that allow a developer only team to build resilient distributed applications.
Having to configure and maintain all the parts that amazon takes care of would cost a hell of a lot more to replicate manually

I find it that AWS EC2 is a lot cheaper actually. You can try Heroku if you quickly want to deploy your app. But it is way too costly if you want to use several resources, and also it uses AWS as it's own backend. I've also tried Google app engine and I found that it is somewhat more costly than EC2 because of its auto-scaling features. I find it more pleasing to configure settings for my server and thus prefer EC2 over any PaaS

If you find AWS expensive then your design is wrong.

@dfox compared to what? The only cheaper alternatives I'm aware of is lower quality vm providers, or bare metal.

You definitely pay a premium for EC2 instances compared with cloud hosts of similar quality. There's a common misconception that EC2 instances are awesome and super reliable. From my experience, they are really no more reliable and certainly not more performant than Vultr, Linode, DigitalOcean, etc.

As for the pricing, for a number of our servers we use 8gb instances which most of the companies I mentioned charge $80/month for. A similar instance on EC2 comes out to about $87 a month and that doesn't include storage.

@sMoOf69 your design is wrong if AWS is expensive? That makes no sense. For us it would cost probably $75/month more than we pay now, for the same specs...

@dfox don't use EC2... Lambda has a free tier and no need for system admin. Front your Lambda with API Gateway

@dfox is $75 enough to actually matter? Is that making use of some reserved instances? If AWS is easier than the alternative, and saves more than an hour or two, surely that makes AWS the cheaper option?

@sMoOf69 looks cool, but the large majority of our costs are DB costs and we're not interested in using DynamoDB or any AWS managed db service. Even with one, our costs would be high as we're a very db intensive app.

I also think when people talk about the cost of AWS they are usually referring to EC2. Plenty of AWS services are very economical for most use cases which is why we use it for a lot of things. In our case, it's more expensive if we wanted to replace our infrastructure with EC2 instances.

@ThomasRedstone why is AWS easier than an alternate solution like DigitalOcean?

And no, not reserved instances.

@dfox because with DO you need to handle *everything* manually, load balancer, database server, cache servers, scaling, centralising logging, auto scaling, none of these things are hard in themselves, but combine it all and you have a lot of extra work keeping everything current and working smoothly
when I was running the numbers last, it didn't really seem cheaper, as you can't even come close to the failure resistance Elastic Load Balancer, but an approximation of two load balances is likely to cost more (ELB uses a huge number of load balancers, but costs $18)
What do you even do to approximate s3?

@ThomasRedstone I think maybe I wasn't clear, but we do use AWS for most of what you listed there. Probably more services than many AWS-only customers. We use S3 (heavily), ElasticSearch service, SQS (heavily), CloudFront (heavily), Route53 (heavily, good for basic load balancing too), and CloudWatch.

DigitalOcean has an API where we could do auto scaling if really wanted to, but so far haven't had any need for it even with massive spikes of traffic at certain times.

My point here is I think it's sensible to chose what AWS services work for you, and for us, EC2 for our web servers and db servers is more expensive for a lesser offering.

@dfox makes sense, I've always avoided having services spread across different data centres, but maybe that's just old fashioned thinking, and latency is a much less serious issue than it used to be!

@dfox out of interest, what latency do you see between DO and AWS?
I was just looking, and realised my AWS region is Dublin, Ireland, but DO would be London, England, which may hurt performance, or maybe I'm still being old fashioned. ;-)

@ThomasRedstone For the latency we see, it's negligible, to the point where we're running SQS requests on a majority of our endpoint requests and it pretty much has no impact on speed. Probably 40ms or less. Our web servers/db servers are in NY, so still a little away from AWS in Virginia.

I think in your case you might see some more latency since it's further, but probably worth a try to actually benchmark it. I think in any case if you tried to send 30 jobs individually to SQS on a single request you'll have some more impactful latency. But for 1 job, or multiple jobs sent in a batch request, I can't see it ever really being a problem.

I think for something like ElasticSearch a little more latency is usually acceptable since it's generally used for queries that are expected to take a bit longer I think.

I'm curious what kinds of speeds you'd see with that geographic setup.