There can be times when you're working on the AWS Cloud where you need to grant limited access to your account to a third-party. For example:

• A contractor or a specialist needs to perform some work on your behalf
• You're having AWS Professional Services or a partner from the Amazon Partner Network do some work in your account
• You're conducting a pilot with AWS and you want your friendly neighborhood Solutions Architect to review something

In each of these cases you likely want to grant the permissions the third-party needs but no more. In other words, no granting of AdministratorAccess policies because it's easy and just works. Instead, adherence to the principle of least privilege.

This post will describe two methods—IAM users and IAM roles—for proving limited access to third-parties.

Given that my technical background is largely in the networking space (exhibit A, exhibit B, exhibit C (CIE)), one of the first things I tried to wrap my head around when being introduced to AWS is how networking works in the AWS cloud.

What I attempted to do was build a mental model by relating cloud networking constructs such as Virtual Private Cloud (VPC), subnets, and routing tables to on-prem, physical networking constructs. This worked pretty well but I did get tripped up at times because some of these constructs don't map exactly one-for-one.

This post will explain the mental model I used while also calling attention to the elements or behaviors that don't map exactly between on-prem and AWS.

In a previous post, I reviewed what a public subnet and Internet Gateway (IGW) are and that they allowed outbound and inbound connectivity to instances (ie, virtual machines) running in the AWS cloud.

If you're the least bit security conscious, your reaction might be, "No way! I can't have my instances sitting right on the Internet without any protection".

Fear not, reader. This post will explain the mechanisms that the Amazon Virtual Private Cloud (VPC) affords you to protect your instances.

So, you've created a compute instance (ie, a virtual machine) on Amazon EC2. Next question: does the instance require access to and/or from the Internet?

Protip: just because you created the instance in the public cloud, i.e. the cloud that you get to over the Internet, it doesn't mean that your instances all need to sit on the Internet. They can have direct inbound and outbound Internet access, no Internet access, or something in between (which I'll explain).

The basic building block for networking on AWS is the VPC (Virtual Private Cloud). Within a VPC, you define your IP space, gateways, ACLs, DHCP options, and more. Gateways will be the focus of this article.

Continuing on with the theme of previous cheat sheet articles, this article will help decode the format for Amazon Web Services' Elastic Compute Cloud (EC2) instance types.

Ok, you've just launched an Amazon EC2 instance (ie, a virtual machine) and you're ready to login and get to work. Just once teeeensy problem though... you have no idea how to actually connect to the instance!

This post will walk through how to log into brand new Linux/BSD and Windows instances (the steps are slightly different for different OS families).

I'd be lying if I said that since starting my new job at Amazon Web Services (AWS), I wasn't looking forward to writing about all the new things I was going to learn. Obviously there's the technology and services that make up the platform itself. But there's also the architectural best practices, the design patterns, and answers to questions like "how does moving to the cloud improve my performance/security/reliability?" Admittedly, I have a lot to learn.