Live data from Hacker News

Things You Should Know About AWS

highscalability.com

41–50 of 51 posts

Re: Things You Should Know About AWS

#41
post #4

This is great and all, but I'd love to see a community wiki / discussion area for AWS tips, tricks, and gotchas. Something like Quora crossed with Wikipedia, just for AWS. Is anyone aware of such a thing? If not, any advice for starting one?

http://aws.amazon.com/forums

+1 this. I haven't seen any type of self-serving moderation here, and using this forum you can quickly see who knows what they're talking about, and if they are affiliated with Amazon or not.

Re: Things You Should Know About AWS

#42
post #10
post #8

Earlier quoted context omitted.

That's the AWS CLI (Command Line Interface), available at http://aws.amazon.com/cli/ .

Is there a huge difference with s3cmd?

I did a drop in replacement of s3cmd by aws s3 and the end result was much better performance, no issues.

Also the 's3cmd sync' and 'aws s3 sync' commands don't have exactly the same heuristic so switching caused a one-time resync of everything.

Re: Things You Should Know About AWS

#43

"9) Use Virtual Private Cloud (VPC) from the start" This is now a no-brainer. New registrations in certain zones will kick you into a basic VPC from the get-go. The only inbound should be via an ELB (HTTP/HTTPS) and an non-DNS-resolvable SSH bastion/NAT host (m1.small is more than enough). Your bastion is the only host that is on the public Internet. Setting up a bastion is reasonably straight-forward. There is an AM…

Why not use a vpn on the bastion?

I guess you could, but I don't see if being that far different from SSH. One mild plus of SSH is you don't have addressing problems (e.g. Wifi network colliding with your AWS one).

Re: Things You Should Know About AWS

#45

Description of noisy neighbor problem #6 lacks some depth. AWS noisy neighbors problem is very often misunderstood. CPU steal time under linux does NOT mean that somebody is stealing your CPU. It simply means that you wanted to use CPU and hypervisor has given it to another instance. This may happen because you have exceeded your quota or scheduling algorithm selected another pending instance at this very moment and…

There was recently [a paper][1] published in ACM Transactions on Computer Systems where the argument was that if your instance is scheduled out by the hypervisor during TCP traffic, the latency in ACKing packets would reduce the network throughput of instances, because of the slow start mechanism.

Given that distributed network rely heavily on network latency and capacity, I found it very interesting to see the effect of busy CPU propagate to slower network IO.

[1]: http://friends.cs.purdue.edu/pubs/SC10.pdf

Re: Things You Should Know About AWS

#46

"9) Use Virtual Private Cloud (VPC) from the start" This is now a no-brainer. New registrations in certain zones will kick you into a basic VPC from the get-go. The only inbound should be via an ELB (HTTP/HTTPS) and an non-DNS-resolvable SSH bastion/NAT host (m1.small is more than enough). Your bastion is the only host that is on the public Internet. Setting up a bastion is reasonably straight-forward. There is an AM…

Can you point to a blog post / article that describes this in greater detail?

Re: Things You Should Know About AWS

#47
post #46

"9) Use Virtual Private Cloud (VPC) from the start" This is now a no-brainer. New registrations in certain zones will kick you into a basic VPC from the get-go. The only inbound should be via an ELB (HTTP/HTTPS) and an non-DNS-resolvable SSH bastion/NAT host (m1.small is more than enough). Your bastion is the only host that is on the public Internet. Setting up a bastion is reasonably straight-forward. There is an AM…

Can you point to a blog post / article that describes this in greater detail?

Funnily enough, working on one :-) It's long overdue though...

Re: Things You Should Know About AWS

#49

Earlier quoted context omitted.

Why does this happen even when the instance isn't using all of its CPU?

>Why does this happen even when the instance isn't using all of its CPU? Probably hypervisor does not assign CPU every time it is requested but it still manages to assign as much as needed because in the end there is some idle time left.

We've seen for example, if we have 5 instances running the same app, one instance potentially uses 20% more CPU with tons of CPU steal time, but none are using 100%, the "normal" ones use ~40% and the one with tons of steal time spikes between 60% - 70%.

But rebuilding the instance brings them all in line.

Re: Things You Should Know About AWS

#50
post #40

Earlier quoted context omitted.

One thing to note with EMR: you still pay 25% of the ondemand price as overhead to use EMR. If you're bringing up and turning off clusters all the time, it's probably worth it, but you might want to look into using Whirr instead.

You've a good point about the EMR charge - that's easy to overlook. I took a look at Whirr [1] but I don't see how having a cloud-agnostic platform helps - are there really alternatives to EMR out there? Can they give me 500+ cc2.8xlarge equivalent machines on-demand but at spot prices? [1] Assuming this is the Whirr to which you refer: https://whirr.apache.org/

Whirr just uses the AWS APIs to provision a cluster for you, but then you're getting a cluster built on EC2 instances rather than EMR, so you don't pay that EMR overhead. You can choose spot or ondemand instances. If your spots get reaped, I think it would fail pretty similarly to an EMR cluster built on spots. I have no idea how quickly it could provision a 500 node cluster, however.
Post reply on HN