The following template will create a CloudFormation distribution with an AliasRecord pointing at it. It assumes your origin is already up and running. You don’t want to have the origin and CloudFront in the same stack anyways.

The best way to ensure some script/command running on shutdown is to use upstart which is the default init in CentOS6:

In order to be able to properly diff and read your CloudFormation templates you want them to be in a harmonised shape:

  1. Validity check and indentation
  2. Apply some regex search/replace transformations to improve human readability

This can be done on the shell: nice-cf.py < template.json > beautified.json

Or in vim using a keybinding:

This is the nice-cf.py Python script used to apply the transformations to the template:

You can SSH to a host inside a private subnet directly by combining the IPs/hostnames with a plus: ssh 54.85.96.204.aws+10.0.1.96

The first IP is added a .aws because I want AWS IPs to trigger usage of an AWS specific config section in ~/.ssh/config that uses a proxy and doesn’t clog up my known_hosts file with SSH host keys of disposable machines.

These are the entries in my ~/.ssh/config that allow the above command to get you straight to your machine:

When you create a new MFA you can put the secret key into an encrypted container with the following command. You need to paste the private key for the MFA device that you can copy and paste when creating a new virtual MFA device in the AWS web console.

gpg --armor -e > ~/.aws/<mfa-name>.mfa.asc

The following snipped will allow you to easily access these MFA devices on the shell (make sure you have the oathtool installed). To get a code just run mfa <profile> and enter your passphrase.

The pbcopy will directly copy the 6digit number to the pastebin on Macs. On Linux you might have to tweak that a little bit to suit your needs.

The following snippet for your ~/.zshrc will look for .aws_profile in the a directory after entering it. In case the file exists it will use the asp function to set your profile according to the content of the file.

This feature is meant to be used in conjunction with the clouds tool for easy CloudFormation stack management from the shell that can be found here: https://github.com/cristim/clouds

You can add as much code as you like to be executed on changing the current directory (e.g. activate a Python virtualenv) but be sure not to overload it or changing directories can become a pain.

In order to use one of multiple profiles in your awscli config you need to set AWS_DEFAULT_PROFILE in your environment. This can easily be done with the following snippet in your ~/.zshrc . Profile names will be autocompleted. E.g.: asp development will activate the development profile from the config section above.

All your profiles live inside ~/.aws/config: