Two years with CloudFormation: lessons learned

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.

The hidden challenges of Serverless: from VM to function

Serverless is a relatively new term. It’s a software development paradigm where the entire concept of a “server” is abstracted away from the development process. You essentially only use managed services that handle scaling, and you pay only for what you use. You no longer need to think about operating systems, security patches, scaling configuration and more. All this is handled for you behind the scenes. The most well-known example is AWS Lambda, though as we will see in this blog post, serverless is much more than that.

How to manage any kind of secret with AWS Secrets Manager

AWS Secrets Manager is a service recently released designed to make the management of secrets easier. It provides built-in support for Amazon RDS, making it very easy to set and rotate secrets and use the CLI or an SDK to retrieve secrets from applications. Through the use of custom Lambda functions, essentially any database or an otherwise protected endpoint is supported. Setting up Secrets Manager for a non-RDS database is less trivial as you need to write your own functionality using AWS Lambda.

Secret management design decisions: theory plus an example

Secret management is one of those security topics that is often an after-thought while designing systems. Passwords are set up manually, shared through non-secure methods such as e-mail or Slack, and password rotation is often neglected because it’s time-consuming and error-prone. This is a shame because with some effort, secret management can definitely be automated. If done properly, less manual work is required to build and maintain applications, and of course security is increased reducing risk.

Comparing AWS SAM with the Serverless framework

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.

Creating a serverless API using AWS API Gateway and DynamoDB

AWS API Gateway is a managed service from Amazon Web Services that allows you to easily create an API endpoint. An incoming request can either be forwarded to an HTTP endpoint, can invoke a Lambda function, or connect to an AWS service. Arguably, the Lambda integration is most commonly used as it allows you to invoke a piece of code without managing a server or operating system (thus, combined with API Gateway, creating a serverless api).

A custom CloudFormation resource example for CodeDeploy

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.

Using pre-signed URLs to upload a file to a private S3 bucket

I’ve written about serverless architectures before (a serverless website in S3 and dynamic image generation with Lambda). I strongly believe in this notion as it minimizes required maintenance and makes the initial setup much easier. Of course, there is no silver bullet for every problem but use cases definitely exist where a serverless architecture makes a lot of sense. One such use case for serverless is a small piece of functionality that you just need to run.

CloudFormation StackSets: automated cross-account/region deployments

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.

Integrating ReactJS with the Google Maps widget

ReactJS is a Javascript library for building user interfaces. The way it ties in with HTML makes it very easy to create interactive components that can easily be reused among different locations within your application. Typically, people build Single Page Applications (SPA) using React. This way, much of the logic required to display a webpage is brought to the visitors’ browser. Instead of HTML, the web server often returns JSON and React grabs this to build the HTML within the browser.