The AWS Iceberg

As I mentioned in my previous post, delving into AWS is like spotting an iceberg. Prior to doing any technical research, I'd already looked at the myriad number of services available in the AWS universe. A lot of it looked like alphabet soup, but I'm happy to say I'm starting to make my way through the alphabet.

The documentation is a bit daunting. It's very thorough, and some of the tutorials are very clear. By and large though, the documentation looks like it's written by a technocrat. Side note - this is a beef I have with a lot of technical documentation, even documentation that's generally universally accepted as 'good.' While I do appreciate a very complete explanation of an API, when I'm starting on something, I'd prefer a narrative tutorial that I can read and re-read (so, not video documentation). Ah, well it seems that I'm more opinionated on documentation than I expected, so maybe that's a post for another day.

Anyway, here's the AWS link that got me started. Prior to actually starting up an instance, I had to run through these steps before introducing myself to EC2. A few notes on the steps:

1. Sign up for AWS - Well, this is a given.
2. Create an IAM user - IAM stands for Identity and Access Management and is the 1st key component in AWS security. Essentially, it allows you to set up users in your AWS systems with certain fine grained permissions.
3. Create a key pair - This allows your IAM users to login into AWS servers using a public/private key pair instead of a password.
4. Create a VPC - VPC stands for virtual private cloud and is set up by default when you sign up for a free tier account. This allows you to take Amazon's virtualized hardware and carve out your own little network. At the scale I'm working at, any service (or additional instance of say, EC2) that I add to my account is added to the VPC and can connect to other services and instances without headache.
5. Create a security group - This is an area I'm definitely interested in exploring more. These groups get tied to IAM users to give them particular permissions (say admin access across services). There are a slew of default options, but I believe these can also be created with more fine-grained permission as well. Having to deal with SOX compliance issues in the past from an auditing perspective, having out-of-the-box capability to restrict users via fine-grained controls is a very powerful possibility.

Even though I've got all of the basic security controls set up, I believe there are still some additional recommendations from Amazon that I need to heed. I'll discuss those in a future post as well.

Well, I was hoping to talk a bit more about my actual EC2 experience, but the post on AWS set up turned out to be a bit longer than expected, so I'll leave that for the next post