Automation is the public cloud's true superpower

Regardless of the platform you use, automated deployments, remediation response, and daily tasks are the public cloud’s real power.

Since all providers are nothing more than a collection of APIs (I like to use the bucket of lego analogy), there’s no right answer on how to automate.

The one thing to keep in mind is that automation is a marathon and not a sprint.

If you’re getting started, it’s crucial not to overwhelm yourself with what’s possible. Instead, start with the tasks you’re already regularly performing and develop a method (or two) to remove the work from your to-do list.

Using the Cloudformation attribute DependsOn to control resource creation

This post is part of a series of introductory articles related to building AWS services using AWS CloudFormation. You can read about CloudFormation Conditions and about CloudFormation Parameters in earlier posts

By default, Amazon CloudFormation deploys resources defined in a template in parallel. When you think about it, this makes a lot of sense; deploying in parallel CloudFormation can reduce the amount of time it takes to create the services you’ve defined in your template.

Using Lambda to Disable IAM Users

Problem

Picture this. You work as a cloud IT professional at a medium size company and you recently hired some AWS contractors. They do a good job, and you get permission to hire more in the future. So you do, and this goes on for some time. However, you get tired of manually removing old contractor users from your IAM groups. What’s an IT pro to do?

Solution

A good way to solve this problem would be to use a scheduled Lambda function and good tagging practices to identify old users and remove their permissions. If you tag any new contractors as role: contractor, you can use a script to identify and remove them from groups automatically using this boto3 method. We will be using the serverless framework to handle the infrastructure deployment for this lambda function. Let’s get into it.

Using EC2 Systems Manager to Maintain your Amazon Machine Images (AMI)

[Amazon EC2 System Manager (SSM)] ( https://aws.amazon.com/ec2/systems-manager/ ) is an agent-based solution that allows you to remotely manage and collect inventory data from EC2 instances as well as on-premise Windows and Linux systems.

Outside of managing long-running EC2 instances, you can also use SSM to manage your [Amazon Machine Images (AMI).] ( http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AMIs.html ) Think of an AMI as a gold-image, it’s a pre-built server image that you can use as part of an [auto-scaling] ( https://aws.amazon.com/autoscaling/ ) solution, reference in a [CloudFormation] ( https://aws.amazon.com/cloudformation/ ) template or when manually deploying an instance via the CLI or through the Management console.

The Why & How of Automated EBS Snapshots

How often do you take EBS snapshots? EBS volumes are automatically replicated across multiple servers in the Availability Zone (AZ) where they were deployed, but for data durability you also need timely snapshots of your EBS volumes.

While it’s possible to manually create snapshots of your EBS volumes, a better, more reliable solution is to leverage AWS Lambda to automate the process.

A Simple Virtual Private Cloud deployed via a Fugue Composition

In part one of this series, I talked about the differences between [Infrastructure as Config, and Infrastructure as Code.] (/blog/code-vs-config/) In this article, we’ll dive into the creation of a simple Virtual Private Cloud (VPC) on AWS using a Fugue composition.

Here’s what we’re going to create. It’s a basic example of a Virtual Private Cloud (VPC) which spans two availability zones (AZ) in a single region. We’re going to create four subnets (two in each AZ, and deploy a NAT Gateway in each AZ for redundancy.

Infrastructure as Code vs Infrastructure as Config

This article is part one of a multipart series exploring the idea of building a true Infrastructure as Code solution on the Amazon Web Services (AWS) platform.

What is Infrastructure as Code?

I’ve talked about this subject a few times and mentioned how important (and popular) the topic was at the various AWS boot camps I’ve had the pleasure of leading. I describe Infrastructure as Code as the process of decomposing the components of your solution into individual pieces, storing these pieces in a centralized code repository and managing them like we would manage our application code. When we need to build a solution, we can take these individual pieces and assemble them to create a complete solution on the AWS platform.

Focus is Greater Than Automation AND Agility

When I first started using Amazon Web Services (AWS) back in 2007, the majority of people I talked to who were interested in leveraging AWS wanted to talk about how they could use AWS to help reduce their IT costs. In the vast majority of cases, those customers were interested in shifting IT related expenses from capital to operating expenditures.

As time went on, a change in how people thought about Public Cloud occurred - rather than using AWS to help them save money organizations now wanted to talk about how they could use AWS to deliver IT projects faster.

Salt Server via CloudFormation

Recently, I’ve been preparing for the AWS Developer Professional Certification. During my prep work, I’ve been reading quite a bit about “Infrastructure as Code.” via CloudFormation and wanted to implement some of the concepts that I had been reading about by working them into a project.

I decided that the project would be to stand up a SaltStack Master server in a VPC by using CloudFormation. Relatively speaking it was quite easy. The most difficult part was figuring out the cfn-init section of the templates responsible for installing the Salt server.