Live data from Hacker News

AWS: the good, the bad and the ugly

blog.awe.sm

71–80 of 88 posts

Re: AWS: the good, the bad and the ugly

#71
post #27

This is a great writeup and is completely on target for realistic deployments on AWS. We're a big user of AWS (well, relative, but we run about $10K/month in costs through AWS), so I'd like to supplement this outstanding blog post: * I cannot emphasize enough how awesome Amazon's cost cuts are. It is really nice to wake up in the morning and see that 40% of your costs are now going to drop 20% next month going forwar…

> We're scared to death of AWS SNS - we currently use SendGrid and a long trusted existing server for email delivery. Twillo will is our first choice for an upcoming SMS alerting project. Can you elaborate on this a bit? Why are you scared of SNS? Data loss / latency etc?

The idea that SNS isn't first-in, first-out is scary enough to me - but the fact that it's also "at least one copy will be delivered" (rather than "only one copy") makes it kind of insane.

Re: AWS: the good, the bad and the ugly

#72
post #37

This is a great writeup and is completely on target for realistic deployments on AWS. We're a big user of AWS (well, relative, but we run about $10K/month in costs through AWS), so I'd like to supplement this outstanding blog post: * I cannot emphasize enough how awesome Amazon's cost cuts are. It is really nice to wake up in the morning and see that 40% of your costs are now going to drop 20% next month going forwar…

What do you see as the benefits of using Elasticache vs your own memcached servers? It seems to me that memcached is so simple to configure and manage that paying a premium to have someone else do it isn't that great of a win. We switched to Elasticache recently as a test, and found that it works fine but don't see any compelling reason not to just manage our own memcached servers. Edit: Also, what scares you about S…

I think SNS was a typo for SES.

Re: AWS: the good, the bad and the ugly

#73
post #61
post #53

Earlier quoted context omitted.

Something that you want to keep in mind with 100TB is that they have pulled companies before, and left them in pretty dire straights. http://gigaom.com/cloud/simplecdn-takedown-a-cautionary-tale... I don't want to try to guess why they did that, but it's something that should never be forgotten.

They recently shut down all the servers of a Chinese reseller with 45 servers after a lot of their servers were the target of a DDOS. It's of course understandable to disable those servers in case of a big DDOS, but the problem was that they gave the reseller 24 hours (during the weekend) to backup the data. It's pretty much impossible to do this in the weekend without even the passwords of the customers. Imagine rec…

Does Tom ever reply in that thread?

Re: AWS: the good, the bad and the ugly

#74
post #31

The elasticity, no capex and api management are great. But bending over backwards to deal with their terrible SAN, saturated layer 2 and low reliability easily wastes at least as much engineer time as it saves in ops. If the OP's 100 boxes are similar to most of the other AWS deployments I'm familiar with it's likely that'd be 10 or less actual machines to manage. Don't get me wrong - the idea is great and it's great…

Pretty much exactly this (I've posted this statement nearly word for word several times in response to articles like this). Basically EC2 or Rackspace Cloud, etc. are very good for small startups running a handful or two of instances, or really large companies that need hundreds/thousands of instances under which scenario hardware might very well be the more expensive option.

Re: AWS: the good, the bad and the ugly

#75

How much does AWS save in terms of admin vs a standard VPS? I assume it runs a standard linux distro, therefor patches , firewalls, dependencies etc are still an issue surely?

Here is actually a real issue with many of these startup type companies using EC2 or similar services... one of the very benefits that are brought up (not needing to have someone building and maintaining servers) is also the person whom generally would be taking care of those services (or abstracting them away with CM solutions).

Many times what I've seen is simply that position is simply 'filled' by developers whom have ideas about designing and securing scalable systems, but when it comes right down to it... they get hacked within some period of time because it turns out, they don't know these things well enough to take the place of someone whom dedicates their time to it.

Re: AWS: the good, the bad and the ugly

#76
To me the decision is simple: if you need less than n servers, AWS is better and cheaper.

OTOH, if you need equal or more than n servers, rolling your own dedicated servers is better and cheaper.

The only issue is to determine the current value of n.

Re: AWS: the good, the bad and the ugly

#77
Yes, ability to clone a new box you don't own in a minutes the only real advantage.

And for that very uncommon requirements you have to pay per Kb and per hour rates for having no service or guarantee at all.

And no, you still need a sysadmin who understand how AWS works and what to do when AWS says "Oops, your "_____" isn't available".)

Re: AWS: the good, the bad and the ugly

#78

How much does AWS save in terms of admin vs a standard VPS? I assume it runs a standard linux distro, therefor patches , firewalls, dependencies etc are still an issue surely?

> I assume it runs a standard linux distro, therefor patches , firewalls, dependencies etc are still an issue surely?

AWS's security groups pretty well cover you on the firewalls front (although some folks like to still run software ones on their instances to be doubly sure), but you're otherwise correct.

For a single instance, you're not going to see significant differences. It's running large clusters of instances you're going to see things being better than the average VPS provider, with stuff like Virtual Private Cloud etc.

Re: AWS: the good, the bad and the ugly

#79

This is a great writeup and is completely on target for realistic deployments on AWS. We're a big user of AWS (well, relative, but we run about $10K/month in costs through AWS), so I'd like to supplement this outstanding blog post: * I cannot emphasize enough how awesome Amazon's cost cuts are. It is really nice to wake up in the morning and see that 40% of your costs are now going to drop 20% next month going forwar…

I don't get the 100tb.com model. Checking out their website, I see: Intel E3-12303.2 GHz8GB2 x 1TB100 TB$201.15 1Gbit Dedicated Port So, for $200/month, they'll give me 100 Terabytes/bandwidth on this server. 250 megabit/second at 30 days in terabytes = 81 Terabytes. A decently peered/connected Pipe costs, at this volume, around $5-$7/megabit @95th, or $1250.month. So either: A) Their connectivity isn't hot. B) If yo…

I don't know about 100tb specifically, but some general notes about the "hundreds of dollars for a dedicated port" market:

yes, the transit is not super. i wouldn't run voice on it, but i'd surely run bulk transfers off of it.

of course they're counting on underuse, that's why it's sold at port level instead of usage

they may not be shaping, but guaranteed you'll see primetime saturation pushing you (way) below port speed

this kind of bw costs them about $0.50/mbit when bought via 10g xc

Re: AWS: the good, the bad and the ugly

#80

How much does AWS save in terms of admin vs a standard VPS? I assume it runs a standard linux distro, therefor patches , firewalls, dependencies etc are still an issue surely?

> I assume it runs a standard linux distro, therefor patches , firewalls, dependencies etc are still an issue surely? AWS's security groups pretty well cover you on the firewalls front (although some folks like to still run software ones on their instances to be doubly sure), but you're otherwise correct. For a single instance, you're not going to see significant differences. It's running large clusters of instances…

I mean assuming that you want to open SSH you are going to need to secure that either using keys or fail2ban. If you have a web server you might need mod_security (or does AWS reverse proxy everything?). If you want remote database access you need to configure that too.

Does AWS provide easier tools for that stuff? Because you can't really cover it with a general firewall.

Post reply on HN