Tips for Getting Started With AWS
jamescarl.us
jamescarl.us
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.
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.
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.
- 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.
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.
I believe the author was referring to navigating the filesystem and running commands via CLI (e.g. `cd` and `ls`, not `ec2-describe-instances`).
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.
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.
Crash Course on the Filesystem Hierarchy Standard @ http://sysadmincasts.com/episodes/12-crash-course-on-the-fil...
Crash Course on Common Commands @ http://sysadmincasts.com/episodes/13-crash-course-on-common-...
Crash Course on Man Pages @ http://sysadmincasts.com/episodes/19-crash-course-on-man-pag...
Edit: Please don't just downvote when I rebut sarcasm/snark with fact. Discuss!
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"?
That the most sophisticated attacker with the most resources may be able to tunnel into your data is no excuse for lax security.
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.
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.
Tip 0.1: Use Vagrant with an EC2 box, and just 'vagrant up' yourself a fully operational machine.
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.
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.
If you're intending to bash Puppet/Chef, why are you doing it in response to someone mentioning how handy Ansible is?
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.
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.
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.
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.
- yum: name=nginx
sudo yum -y install nginx2nd, know your usage upfront before you incur thousands of dollars in usage fees! services like dynamoDB can become very expensive very fast!