Live data from Hacker News

AWS mistakes to avoid

cloudonaut.io

181–190 of 276 posts

Re: AWS mistakes to avoid

#181
post #154

Earlier quoted context omitted.

We started with Linode. We moved to AWS. Here's the main reason: you can't decouple disk space from RAM. So we paid thru the nose just to get more disk space. With AWS it's pay for what you need. That's the killer feature for us.

Sure but you could have also just moved to SoftLayer or any number of dedicated hardware providers for the same, cheap probably cheaper, result.

Which ones decouple disks from computer instances when it comes to paying?

Re: AWS mistakes to avoid

#182
post #150

Earlier quoted context omitted.

I simply don't believe the $250 - $20,000 month comparison. Could you please provide some real-world numbers/hardware/stack information? I just did this migration (non-AWS -> AWS), and we saw a ~20% reduction in monthly prices with 1-year contract at AWS vs. physical hosting (admittedly we were getting terrible pricing with our physical hosts, but still). This will be reduced with the addition of t2.nano servers as w…

Your parent is [rightfully] including bandwidth. If he was able to get 1gbps unmetered, then the math is in the right ballpark (that's a huge if though). Still, I agree with the parent's general sentiment re price. The gap used to be much worse, but it's still anywhere from 2x-20x depending on what you're doing. - EC2 prices are simply high and exclude things like bandwidth. - The CPUs are usually 1-3 generations beh…

This is correct. The biggest cost I saw was bandwidth, followed by cycles on their machines. MediaCrush was a "media hosting website" (see original comment) and as such, used a lot of bandwidth and did a lot of work transcoding things, and had a large storage requirement.

Re: AWS mistakes to avoid

#183

Earlier quoted context omitted.

What? Implement RDS/SQS/Redshift myself? That is not easy, believe me.

It's not easy, but also not every difficult. The company I work for has two Dev Ops (only one until a year ago) and runs on AWS serving millions of users. We are using MySQL RDS, but are migrating to self-managed Cassandra. We use RabbitMQ instead of SQS. We use Hive/Presto instead of Redshift.

You sure can adapt the open-sourced solution, though I don't think Cassandra/Presto can match up to what RDS/Redshift can offer.

The key point is, running those things yourself, you are likely to lose all the nice failover mechanisms/monitoring/auto-snapshotting stuff that AWS offers. To live up to that, it will require you to not only have extensive understanding of the software you are running, but also a considerable amount of your time will be dedicated to Ops side, which can lead to some really big frustration from time to time. In that sense, I don't think you can re-IMPLEMENT something by assuming too much of comprises.

Re: AWS mistakes to avoid

#184
post #150

Earlier quoted context omitted.

Your parent is [rightfully] including bandwidth. If he was able to get 1gbps unmetered, then the math is in the right ballpark (that's a huge if though). Still, I agree with the parent's general sentiment re price. The gap used to be much worse, but it's still anywhere from 2x-20x depending on what you're doing. - EC2 prices are simply high and exclude things like bandwidth. - The CPUs are usually 1-3 generations beh…

This is correct. The biggest cost I saw was bandwidth, followed by cycles on their machines. MediaCrush was a "media hosting website" (see original comment) and as such, used a lot of bandwidth and did a lot of work transcoding things, and had a large storage requirement.

Were you comparing bandwidth/data transfer in your numbers for EC2, S3 or CloudFront?

Re: AWS mistakes to avoid

#185
post #92

> There is no reason - beside manually managed infrastructure - to not decrease the instance size (number of machines or c3.xlarge to c3.large) if you realize that your EC2 instances are underutilized. CPU/Memory aren't the only measures of underutilization. If you require high instantaneous bandwidth throughput, then the networking capacity available to your instance roughly increases with the size of your instance.…

This is super important - I've run a number of 'oversized' instances just to get better networking. AFAIK none of the cloud providers offer a way to create a 'network' optimized instance, though containerized deployments should help with under utilizing the rest of the instance.

This was a big issue for me too. Google Compute Engine seems to have no throttling like AWS does, or at least it's a much higher cap. On an n1-standard-1 I routinely get 250+ MB/s, and near 1 GB/s for n1-standard-4 and larger. The only high bandwidth AWS instances I've found are the few expensive ones that spec 10 Gbit.

Re: AWS mistakes to avoid

#186
post #150

Earlier quoted context omitted.

I simply don't believe the $250 - $20,000 month comparison. Could you please provide some real-world numbers/hardware/stack information? I just did this migration (non-AWS -> AWS), and we saw a ~20% reduction in monthly prices with 1-year contract at AWS vs. physical hosting (admittedly we were getting terrible pricing with our physical hosts, but still). This will be reduced with the addition of t2.nano servers as w…

Your parent is [rightfully] including bandwidth. If he was able to get 1gbps unmetered, then the math is in the right ballpark (that's a huge if though). Still, I agree with the parent's general sentiment re price. The gap used to be much worse, but it's still anywhere from 2x-20x depending on what you're doing. - EC2 prices are simply high and exclude things like bandwidth. - The CPUs are usually 1-3 generations beh…

[deleted]

Re: AWS mistakes to avoid

#187

Earlier quoted context omitted.

This is correct. The biggest cost I saw was bandwidth, followed by cycles on their machines. MediaCrush was a "media hosting website" (see original comment) and as such, used a lot of bandwidth and did a lot of work transcoding things, and had a large storage requirement.

Were you comparing bandwidth/data transfer in your numbers for EC2, S3 or CloudFront?

I don't know, it was an anecdotal story from a while ago. Before we left AWS we were utilizing all three (iirc these numbers didn't factor in CloudFront though). Point I'm making is - do the research and don't just reach immediately for AWS.

Re: AWS mistakes to avoid

#188

Earlier quoted context omitted.

Were you comparing bandwidth/data transfer in your numbers for EC2, S3 or CloudFront?

I don't know, it was an anecdotal story from a while ago. Before we left AWS we were utilizing all three (iirc these numbers didn't factor in CloudFront though). Point I'm making is - do the research and don't just reach immediately for AWS.

Oh okay I was just curious. I completely agree. The AWS bill at my startup went up quite a bit after the free trial ended since there are many variables that are included with each service such as how many requests/mo, tiered bandwidth, etc. The AWS calculator is nice and so is the billing estimator, but it's still quite confusing.

Re: AWS mistakes to avoid

#189
post #149

Earlier quoted context omitted.

Since you're dealing in absolutes, let me return the favor; you're being a little silly. Yes, Linode beats AWS when it comes to price. On the other hand, Linode's offer is incredibly basic and simplistic. AWS offers service after service that Linode simply doesn't and realistically cannot. Sure, you can emulate a subset of these services (and a subset of their features) using open-source software but at what price ?…

I'm really not trying to compare Linode to AWS here. I just felt that it was necessary to mention that I work for Linode because there _is_ some overlap. I'm really also not trying to sell anyone on Linode in particular. I'm pointing out that from my own personal experience, AWS is grossly overpriced and worse than the alternatives for a large number of use-cases.

AWS is insanely overpriced. It's weird to me that everyone jumping on AWS and some of their customers never come close to attracting the internet traffic required to set up CloudFormation. I think if you're starting a webapp out of your own pocket and not millions of dollars of investors, it makes sense to save where you can.

Using locust.io, I've seen that my current site on two $10/month Linodes can scale up to approximately 300k people/day and increasing that substantially just means I press a button and upgrade my app/database servers.

If it came to a point where I was growing at a pace I didn't want to manage and money was flowing in, and I was out of ideas on software optimization, only then I would consider spending tens of thousands/month on AWS.

I'm not denying the great benefits AWS gives, I honestly would love to use it now and just be done with most of my devop headaches, but the costs are prohibitive.

Re: AWS mistakes to avoid

#190
post #149

Full disclosure: I work for Linode and I am super biased. This is my own opinion etc etc Perhaps the first AWS mistake you might make is... using AWS? Even before I started at Linode, I thought it was terrible. It's extremely, unreasonably pricey. The UI is terrible. Their offerings are availble elsewhere. I started MediaCrush, a now-defunct media hosting website, on AWS. After a while, we switched to dedicated hosti…

Since you're dealing in absolutes, let me return the favor; you're being a little silly. Yes, Linode beats AWS when it comes to price. On the other hand, Linode's offer is incredibly basic and simplistic. AWS offers service after service that Linode simply doesn't and realistically cannot. Sure, you can emulate a subset of these services (and a subset of their features) using open-source software but at what price ?…

[deleted]
Post reply on HN