Live data from Hacker News

Tips for Getting Started With AWS

jamescarl.us

31–40 of 56 posts

Re: Tips for Getting Started With AWS

#31
post #28

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.

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.

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.

Re: Tips for Getting Started With AWS

#32

Earlier quoted context omitted.

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

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"?

It's actually kind of hard to remember sometimes that cloud-compute providers don't employ some sort of homeomorphically-encrypted VM containers. Even though they are completely impractical and have never even seen a proof-of-concept, the idea is so intuitive that I bet if you asked a random non-IT manager if Amazon could read memory or CPU registers on the instances his employees have running on EC2, he'd say no. "Because obviously," he'd pontificate, "nobody would be using cloud-computation otherwise."

Re: Tips for Getting Started With AWS

#33

Earlier quoted context omitted.

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"?

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.

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.

Re: Tips for Getting Started With AWS

#34

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 unle…

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.

True, all new AWS accounts create VPC based configs. http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/defaul...

Re: Tips for Getting Started With AWS

#35
post #32

Earlier quoted context omitted.

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"?

It's actually kind of hard to remember sometimes that cloud-compute providers don't employ some sort of homeomorphically-encrypted VM containers. Even though they are completely impractical and have never even seen a proof-of-concept, the idea is so intuitive that I bet if you asked a random non-IT manager if Amazon could read memory or CPU registers on the instances his employees have running on EC2, he'd say no. "B…

I agree with this.

If I want my data to be very secure, its going to run on VMs that boot and run entirely in RAM, read the encrypted data in from persistent storage, and have their power controlled by an intrusion detection system. If you attempt to open the rack, power is removed, unencrypted data is lost, and everything is safely encrypted at rest.

You would only need this security for the most sensitive types of data though.

Re: Tips for Getting Started With AWS

#38
post #28

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.

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.

How do you create that initial AMI? CMs make answering that question simple.

AMIs are nice - but they're merely snapshots of an end product. Being able to get to that end product in a repeatable, idempotant and self-documenting fashion is just as nice.

So is being able to create a virtual image on your own machine with the same end product.

FWIW, Vagrant lets you specify an AMI in its box description, so you get the best of both of your worlds there.

Re: Tips for Getting Started With AWS

#39

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 unle…

regarding ELBs, if you have a support contract with AWS you should be able to get them to "pre-warm" them if you are expecting a spike

Re: Tips for Getting Started With AWS

#40
post #2

> 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…

What about encrypting your pem file with AES (using 7zip on a Windows or OpenSSL on *nix) and then backing it up to the cloud?

And your IV and key for the AES encryption ... are you going to back that up to the cloud too? :-)
Post reply on HN