Live data from Hacker News

Open Guide to Amazon Web Services

github.com

111–120 of 133 posts

Re: Open Guide to Amazon Web Services

#111
Great work! I started using AWS back when it was just simple websites, and the plethora of services now (50!), and pricing (especially pricing!), is overwhelming to track.

So overwhelming, in fact, that I decided it was easier to get some VPSs and use common, work anywhere, tools to manage (e.g. saltstack), than have to skill up on AWS specific stuff.

Re: Open Guide to Amazon Web Services

#113
post #11

Wow, the link to http://www.ec2instances.info/ alone is so helpful. I wish I'd had this set of resources a year ago when I spent weeks trying to understand AWS' own documentation.

This is awesome. Almost everytime I've to launch an instance for a new app or something, I end up googling "aws ec2 instances", "ec2 pricing" etc.

Re: Open Guide to Amazon Web Services

#115
post #107
post #84

Great guide. I've been using AWS since there were only a handful of services and it's become increasingly hard to keep up with all the additional ones that have been added in the last few years. EFS had completely passed me by. Does anyone have experience with it? I'm wondering what it would be like to use for Whisper / Graphite (just on a single machine). I'm less interested with concurrent access and more intereste…

The latency is higher than I had hoped. I wrote 10,000 files with 10 kb in each. It took 23 ms per file on average. Then I read them back. That took 8 ms per file on average. That's way too much for the use case I was contemplating, so I didn't investigate further.

It definitely _felt_ a bit slow rysncing to it last night. In the Whisper use-case, there are a ton of small appends to do every minute - so that could be an issue. I'm going to set up a machine with a linux 4 kernel today to try it on (as that's what they recommend, along with async mode).

Re: Open Guide to Amazon Web Services

#116

Earlier quoted context omitted.

Right? I wish Amazon were just running a page like that themselves.

Which aspect of it do you find the most useful? * All of the instance types on one page? * All of the per-type facts in one row? * Sorting? Let me know and I will share it with the team.

* All information on one page with sortable columns

* Filters!

* Ability to see pricing cost per hour, daily, weekly, monthly and yearly

* Quick and easy to switch between regions

* The compare selected feature

My wishlist for this site would be a way to easily compare pricing information between regions.

Re: Open Guide to Amazon Web Services

#117

Earlier quoted context omitted.

Right? I wish Amazon were just running a page like that themselves.

Which aspect of it do you find the most useful? * All of the instance types on one page? * All of the per-type facts in one row? * Sorting? Let me know and I will share it with the team.

[deleted]

Re: Open Guide to Amazon Web Services

#118
post #81
post #48

Earlier quoted context omitted.

Been using opsworks for about a year now and while it has very significantly streamlined our provisioning/deployment tasks, "nothing but love" is not quite how I'd describe it. It does have some warts.

Biggest wart we have is that it randomly picks a machine to run migrations on, if it's a deploy with migrations.

You could code up something in the deploy hook to select the master node (mostly the first instance in the layer) to run migrations and you could disable the "Run Migrations" when you deploy. I do this for the Rails app in my company.

Re: Open Guide to Amazon Web Services

#119
> A single EBS volume allows 10k IOPS max. To get the maximum performance out of an EBS volume, it has to be of a maximum size and attached to an EBS-optimized EC2 instance.

Out of date; EBS volumes can be up to 20k IOPS per volume and what is "maximum size"? To get the maximum performance out of a volume depends on workload, the instance size you've attached it to (rather than EBS Optimization) and the number of IOPS provisioned, and whether you've prewarmed it from a snapshot restore or not.

> A standard block size for an EBS volume is 16kb.

A block can be 1kb -> 256kb in size. It depends on the application.

> EBS volumes have a volume type indicating the physical storage type. The types called “standard” (st1 or sc1) are actually old spinning-platter disks, which deliver only hundreds of IOPS — not what you want unless you’re really trying to cut costs. Modern SSD-based gp2 or io1 are typically the options you want.

The ST1/SC1 wording is misleading. You only need '100s' of IOPS when dealing with big blocks for ST1, and SC1 isn't performance oriented at all.

Post reply on HN