Cloudformation on Sander Knape

Blocking account-wide creation of public S3 buckets through a CloudFormation custom resource

Fri, 16 Nov 2018 17:25:02 +0200

Yesterday, AWS announced the release of an important and much-wanted new feature for S3: blocking the creation of public S3 buckets on an account-wide. Enough has been written already about open S3 buckets on the internet. Given that it is very simple to create a public S3 bucket, we regularly learn about new (big) companies that have exposed privacy-sensitive data to the world through such buckets.

The confusion is mainly around opening up your bucket to “everyone”. Where people expect this to mean “everyone in the AWS account”, it actually means “everyone in the world”.

Two years with CloudFormation: lessons learned

Thu, 09 Aug 2018 12:43:02 +0200

It’s been close to two years since I started working with AWS CloudFormation, the Infrastructure as Code solution by and for AWS. With CloudFormation you can describe and provision your entire AWS infrastructure in code.

The entire AWS environment I work with is provisioned through CloudFormation - we only have read-only access to our AWS accounts. We now work with a number of different VPCs and many different AWS services. We currently have close to 300 stacks provisioned, describing the foundational networking and over a hundred different applications. All these stacks are deployed in three different accounts (testing, acceptance and production), with CloudFormation giving us the confidence that all these accounts are almost exactly the same (with minor exceptions such as that we run less resources in testing and acceptance to reduce costs).

Comparing AWS SAM with the Serverless framework

Thu, 22 Feb 2018 20:39:02 +0200

Serverless applications are everywhere these days. Having been introduced some years ago with the introduction of AWS Lambda, today serverless is much more then Function as a Service (FaaS). AWS is even starting to use the term in their products: at AWS re:Invent 2017 “Aurora Serverless” was introduced, a fully managed RDMS database.

How do you build such applications? Given that you properly like the Infrastructure as Code mindset as much as I do, the question is how to properly specify serverless applications provisioned in AWS in code. Two main options are out there: the Serverless Framework and AWS SAM. Both frameworks allow you to make it easier to build serverless applications.

A custom CloudFormation resource example for CodeDeploy

Thu, 17 Aug 2017 21:25:02 +0200

CloudFormation is the AWS product for Infrastructure as Code. It allows you to provision AWS resources through a template that describes how to configure that resource. Unfortunately, CloudFormation will sometimes be behind on new features released by AWS. Where the AWS console and API will allow you to deploy resources with a certain configuration, in CloudFormation specific settings might simply not yet be available. If its your goal to deploy your AWS environment completely through Infrastructure as Code, this will block you from doing that. Luckily, through custom resources, CloudFormation allows you to extend the templating language and still give you the option to provision resources entirely through CloudFormation.

CloudFormation StackSets: automated cross-account/region deployments

Wed, 26 Jul 2017 19:53:02 +0200

Yesterday, AWS released CloudFormation StackSets. A StackSet is a set of CloudFormation stacks that can easily be deployed to multiple AWS accounts and/or multiple AWS regions. Before, each stack had to be deployed separately and custom scripts were required to orchestrate deploying to multiple accounts/regions. Therefore, this feature is bound to make the lives of AWS administrators a bit easier.

There are loads of use cases for deploying stacks to multiple locations. For example, it’s considered a best practice to enable AWS Config in every region. This service keeps track of resources in an AWS account and changes to those resources. AWS Config needs to be enabled in every region separately, so a CloudFormation stack is required for every region.

Use Infrastructure as Code for automated security in the deployment pipeline

Mon, 01 May 2017 19:25:02 +0200

Infrastructure as Code (IaC) is a very powerful concept. The idea is that you put all infrastructure resources - networks, subnets, load balancers, firewalls and so on - in code. You then deploy your infrastructure the same way application developers deploy their code: through a continuous integration / continuous deployment (CI/CD) pipeline. Other benefits already reaped by application developers that become available are code linting, automated testing and an audit trail of your changes if combined with a version control system. The most well known IaC tools are Terraform (supports many different services) and CloudFormation (specifically for the AWS cloud).