When creating a new AWS Account, I typically do the following:
Create the CloudTrail Create a Deploy Bucket Create Generic Alert topics for the account and subscribe my email and cell Create a stack to send certain cloudwatch events to a slack channel Configure requireMFA Configure Password & API Key Expiration Warning All of these are done via automation of course
Note: The deploy stack script has been superceeded with cft-deploy, which you can get from pypi via pip install cftdeploy. deploy_stack.rb is not being updated.
Deploying Cloudformation templates via the CLI is a complex process that lack repeatability. Typing out long command lines, and then having to execute other commands either before or after the stack runs results in lots of custom scripting. Rather than go down that route, I created a tool that takes a yaml manifest file that allows you to specify all the details around your stack deployment in one data-driven place.
When I’m creating a new AWS account, I find it helpful to have a generic set of SNS topics that ping me and my team if something goes wrong.
The following CloudFormation template can be used for that purpose. It requires a few parameters and includes an optional Lambda that will send the alerts to a Slack Channel.
Three Topics are created for critical, error and info-level alerts. Critical alerts will send me a text and email, while error only sends an email.
When AWS announced Lambda at the 2014 re:Invent, my immediate thought was “Cool, you can now program the cloud itself”. Since then, everyone has jumped on the “serverless” bandwagon for building apps. After this year’s re:Invent I’m inspired to get back to using Lambda to program the cloud.
One of the sessions I attended was on Security Automation. I’ll have more to say on that later. However, it gave me the idea for a setup that would require users to have MFA enabled, or otherwise be blocked from doing anything with their IAM User in the AWS account.
I passed the AWS Certified Solutions Architect – Professional Level exam this morning. The combination of all the reading and Vegas’s dry air has given me major eye aches.
My VP, Michael Koetter, gave a presentation in the Media Track at re:Invent on the AWS-based Content Supply Chain we’re building.
You can check it out here:
Plus a Link to SlideShare.net where you can see one of my diagrams: http://www.slideshare.net/AmazonWebServices/aws-reinvent-2016-turners-cloud-native-media-supply-chain-for-tnt-tbs-adult-swim-cartoon-network-cnn-mae302
AWS API Keys are powerful things that you don’t want to leave lying around. Amazon’s suggestion is to keep them in ~/.aws/config. I’m not a fan of that. OSX has KeyChain, which is a secure repository for credentials and what most OSX Apps use for caching your login to various websites. This might not be the ideal solution, but it’s better than an unencrypted file in your home directory.
I’ve built a set of three scripts that will use OSX Keychain to store your AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY, and retrieve them into environment variables when needed to use the AWS API or any script that honors those environment variables.
We’re getting ready to deploy our first production workload in AWS, and our AWS account team recommended we enable a bunch of auditing on our accounts in each region. That is a lot of clicking for 9 regions across three accounts.
This script will configure AWS CloudTrail and AWS Config Service in all regions, configure the logging bucket, and establish a reasonable password policy. Amazon is about to release 3 (or four) more regions in Ohio, England, Korea and India.
