> 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.
A few things you can do back up your private key safely (correct me if I'm wrong here.)
- Encrypt the pem file with a gpg passphrase you can memorize or put in a password manager
or
- Create a new IAM AWS account with a strong password, turn on 2-factor authentication, and grant access to the keys bucket for just that account. Make sure you turn on S3-side AES256 bit at-rest encryption for the file.
The latter still has the risk of a complete AWS breach and S3 encryption key compromise, or someone hacking into your admin account somehow (in which case you have bigger problems), but that seems much less likely than say someone just snagging your laptop and getting the key off of it.
In practice I have a single jump node in a VPC facing the internet in a security group with my IP whitelisted that has 2-factor authentication with a PAM module for google authenticator and a strong password, so they would need my phone, the password, my IP, and the backend nodes' private key to get to any machine.
> 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.
By all means, have a separate, passphrase-protected key for each separate device (desktop, laptop, tablet) and push them to your machines using something like chef and the 'users' and 'sudo' community cookbooks, at a minimum, and destroy the .pem after you initially set up the host.
There is a reason that Amazon only configures one user with only one key, and it's not because that's how sane people access their machine.
If that's the case, it's kinda pointless advice - none of the commonly used Linux AMIs have GUIs installed, and someone who can install X on one probably knows the CLI already.
If you keep one key per device, you can revoke it if/when that device is compromised, stolen, etc..
That key is for initial access to provision your machine, after which you should have a more sophisticated means of managing users, as certainly, if you are doing anything of much importance, you will eventually need at least 2.
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.
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.
> - 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.
This is only true in the "US Standard" region. Other regions get read-after-write consistency (but not read-after-update, read-after-delete, etc). "US Standard" is the only bi-coastal S3 region, so I guess that consistency level would be too expensive, latency-wise.
I really apologize for wasting your time perhaps I will post these as a question next time. In any case I sincerely appreciate the feedback and your additional tips.
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.
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.
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"?
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.
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.
>How do you create that initial AMI? CMs make answering that question simple.
No, they make it slower and more complex. The idea being that after you have built a config, future clones will be easier. But you already get a better solution just setting up a server and then making an AMI from it. Cfengine and friends offer quite literally zero benefits for this sort of scenario.
You missed two points. How did you create that first image? Exactly what versions of packages, packages, configurations, etc were installed? Being unable to answer that question will hurt you more in the long run than you might expect.
Second, if you should move from AWS to (as an example of a second popular PAAS provider) Rackspace, how do you recreate that image? If you want to create a local VM to perform development on, how do you do that?
Now, if I were limited to just using one CMS, I might agree with you. There are some really obtuse ones out there that require a lot of learning. I don't think Ansible falls into this category. You're not writing python, you're not writing in some tool specific DSL, you're writing lists of packages, to be installed in-order. Simple and straightforward.
I didn't miss any points. Every package manager can accept a list of packages. You missed learning the most basic fundamentals of your OS. And once again, the specific tool does not matter. They all do the same thing, and they all do it in an error prone and ill-conceived way. Hell, nix is a better "CM" tool than the real ones, and it is just a package manager.
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.
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.