

Tips for Getting Started With AWS - jamescarl
http://jamescarl.us/blog/5-tips-for-getting-started-with-aws/

======
ceejayoz
> For the love of all that is good, save your .pem file to some kind of cloud
> storage so you’ll never be without it.

For the love of all that is good, don't do this for anything beyond random
hobbyist screwing around. A Dropbox compromise shouldn't risk your entire
company's server infrastructure.

> If you only have need for one free tier instance leave it running.

No, because the 750 hours/month can be used by more than one instance. You
could, for example, try out database clustering by running two t1.micro
instances for two weeks.

> Finally resist the urge to use your GUI when working with your project even
> when your working with your project on a local machine you’ll find that as
> you move along with your project you’ll be in better control of the project
> when it’s on the remote server.

The AWS Console is perfectly usable for 99% of what you'll need to do. Most
users won't need anything beyond it.

~~~
oneeyedpigeon
> For the love of all that is good, don't do this ...

I, too, was astounded that anybody would be recommending keeping your keys
'public' like this. By all means, keep it on a few USB sticks that are nicely
secure - and have a good plan in place in case you lose one.

~~~
justinwr
Here's a better idea. Learn to use IAM properly and rotate your keys on a
schedule.

~~~
gfodor
You're thinking of AWS access keys. Not the same thing.

~~~
justinwr
Oh, I thought this article was about AWS not SSH. My bad. Yeah, don't rotate
your SSH keys either.

------
euphemize
A bit disappointed by this. As mentioned by ceejayoz, don't upload your .pem
file anywhere!

AWS has tons of weird/interesting quirks - I thought this article was going to
be about those.

Here's my 5 tips for AWS...

\- SQS: encodes messages by default! plan accordingly if you are going to be
sending large bodies (265K max).

\- ELBs: they need time to warm up if you get a huge traffic spike. ELBs won't
start scaling unless that traffic is sustained for a certain time (usually
minutes).

\- S3: watch out for "eventual consistency" if you're going to upload lots of
files and try to access them right away - they might not be available
immediately.

\- Cloudwatch: set up alarms to make sure your billing never goes over
threshold X in time Y. If someone compromised your account (because you
uploaded your .pem file in cleartext to dropbox) and is mining bitcoins on
your machines, you'll be notified.

\- VPC: if you're going to build a services-oriented infrastructure, consider
using a VPC! Unless you need to have all your services exposed to the public
internet, it could save you a lot of time and security configuration trouble.

~~~
ceejayoz
On the last point, just use a VPC, period. I believe Amazon has now made this
the default for new accounts, in fact. They come with no downsides and lots of
benefits - being able to change security groups on the fly, elastic IPs that
stay with the instance when stopped, etc.

~~~
dmourati
True, all new AWS accounts create VPC based configs.
[http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/defaul...](http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/default-
vpc.html)

------
WestCoastJustin
If you choose to upload .pem to cloud storage, make sure you secure (encrypt)
your .pem file, since it allows total access to the boxes! You should also
secure remote access via the "security groups" firewall by only allowing known
ip addresses (you can edit this via the aws console as needed). Since he
mentioned the "The Command Line Crash Course" [1]. I might chime in with a
couple into screencasts I've created.

Crash Course on the Filesystem Hierarchy Standard @
[http://sysadmincasts.com/episodes/12-crash-course-on-the-
fil...](http://sysadmincasts.com/episodes/12-crash-course-on-the-filesystem-
hierarchy-standard)

Crash Course on Common Commands @ [http://sysadmincasts.com/episodes/13-crash-
course-on-common-...](http://sysadmincasts.com/episodes/13-crash-course-on-
common-commands)

Crash Course on Man Pages @ [http://sysadmincasts.com/episodes/19-crash-
course-on-man-pag...](http://sysadmincasts.com/episodes/19-crash-course-on-
man-pages)

[1]
[http://cli.learncodethehardway.org/book/](http://cli.learncodethehardway.org/book/)

~~~
toomuchtodo
I suggest using a TrueCrypt volume with your credentials, stored on Dropbox.

~~~
MichaelBurge
I email myself my encryption passwords so that I - and any interested
government agencies - can log in without me needing to remember them all the
time.

~~~
toomuchtodo
Worry not, I'm sure the US government would just go straight to AWS. No need
to get your private key from you.

Edit: Please don't just downvote when I rebut sarcasm/snark with fact.
Discuss!

~~~
cpucycling
AWS does not have your private key, that's how public key infrastructure
works. ;)

~~~
toomuchtodo
Once you have physical access, no need for the private key. Unless you're
encrypting all of your data, they'll just snapshot your VM to go through it
later (or your EBS volume, depending on where the data is stored).

And yes, you can write out whatever is in RAM just as easily.

Did everyone forget that "cloud" means "someone else fully controls the
hardware"?

~~~
cpucycling
Right, but this has nothing to do with the practice of protecting your private
key.

That the most sophisticated attacker with the most resources _may_ be able to
tunnel into your data is no excuse for lax security.

~~~
toomuchtodo
I was replying to this parent post: "I email myself my encryption passwords so
that I - and any interested government agencies - can log in without me
needing to remember them all the time."

Yes, you should protect your private key. No, protecting it isn't going to
stop a government agency. A VM is not Schroeder's cat: you can peak without
there being any evidence. That was my point. Apologies if I wasn't
straightforward in my explanation.

------
falcolas
My tip number 0: Use a CMS. It's a beautiful thing to start an ec2 instance,
run Ansible, get a drink of water, and return to a fully provisioned and
configured machine.

Tip 0.1: Use Vagrant with an EC2 box, and just 'vagrant up' yourself a fully
operational machine.

~~~
Sssnake
Why are people so thrilled about a slower more error prone way to do what
amazon provides already? Just make an ami for each kind of server you want.
Now you skip the waiting part, and the "oops, my pile of messy ruby scripts
fucked up configuring the server" parts.

~~~
ceejayoz
You can use Ansible to create an AMI to get the best of both worlds - fast
provisioning, plus the ability to make new AMIs in a repeatable, self-
documenting manner. You're arguing configuration management is "error prone",
but I've found it a lot _less_ error prone than other methods. If something
doesn't install right I can blow away the whole thing rather than trying to
un-break a destroyed install.

If your Ansible scripts are in Ruby you've done something very odd, and if
they're messy it's your own fault. Mine are pretty clean, and once built they
work the same way for subsequent runs.

~~~
Sssnake
>If your Ansible scripts are in Ruby

The popular options are in ruby. Just because you use a less popular one that
is written in python doesn't change the main point.

~~~
ceejayoz
Ansible itself is Python, and the docs all use Python examples. I've yet to
come across a Ruby one...

~~~
Sssnake
Why are you replying if you can't be bothered to read?

~~~
ceejayoz
The post you replied to was about Ansible (which is pretty popular).

If you're intending to bash Puppet/Chef, why are you doing it in response to
someone mentioning how handy Ansible is?

~~~
Sssnake
[http://www.nizkor.org/features/fallacies/straw-
man.html](http://www.nizkor.org/features/fallacies/straw-man.html)

~~~
ceejayoz
[http://en.wikipedia.org/wiki/Non_sequitur_(logic)](http://en.wikipedia.org/wiki/Non_sequitur_\(logic\))

~~~
Sssnake
Seriously? Read the thread. You responded to "Using config tools isn't
helpful" with "but mine is python!!1". Nobody cares, it is a completely
irrelevant detail. I simply said ruby because the two popular options are both
ruby. It still applies to fucking cfengine, it doesn't matter the specific
tool.

~~~
ceejayoz
The Ruby-based CMSes are very, very different from tools like Ansible. That's
an important issue when you're bashing the entire range, seemingly without any
thought for the situations that make them useful and without knowledge of
other options than Puppet/Chef.

~~~
Sssnake
>The Ruby-based CMSes are very, very different from tools like Ansible

No they are not. I've probably been doing system administration longer than
you have been alive. I've used everything from cfengine to salt. They all
cause more problems than they solve.

------
johnnymonster
#1 tip Know your AWS service limitations before you start using it!
specifically with services like Cloudsearch and dynamodb!

2nd, know your usage upfront before you incur thousands of dollars in usage
fees! services like dynamoDB can become very expensive very fast!

------
Kiro
Don't listen to these comments. I urge EVERYONE to save their perm files
somewhere. Trust me, the rist of getting compromised is nothing compared to
the risk you're exposing yourself to if you don't.

~~~
jamescarl
Simple! Excellent point thanks for posting.

------
johnnymonster
how did this make it to the front page of HN?

~~~
jamescarl
beginners luck ;)

------
alexchantastic
Just a bit of advice, the body font you chose is terrible at smaller sizes.

~~~
jamescarl
Okay cool. I'll be sure to try out some new ones.

