Building a static serverless website using S3 and CloudFront

Hosting static websites is great. As they only contain static assets to be downloaded by the visitor’s browser - think HTML, CSS, Javascript, Fonts, images - no server-side code such as Java or PHP needs to be run. They’re therefore typically faster to load than dynamic websites, they have a smaller attack surface, and are easier to cache for even better performance. That is why some time ago I moved this blog from a Wordpress installation hosted on EC2 to a static website.

Roundup of the most important pre-re:Invent 2019 releases - so far

The most exciting time of the year for AWS Enthusiasts is upon us. In exactly seven days, AWS re:Invent 2019 will kick off and everyone is excited to see what great features will be released and announced this time around. This year especially though, many new features are already released the weeks leading up to re:Invent. If you haven’t been paying attention, it was easy to much some great new announcements.

Five ways to enable developer autonomy in AWS

It hasn’t been that long since it was normal to request compute capacity at some operations department within your organization. In fact, it’s probably still pretty common in some organizations. With the move to virtualization and especially the cloud, this process of course has changed dramatically for the good. Not only compute capacity for applications, but also resources such as databases, queues, load balancers and storage are now available virtually unlimited.

Installing private Git repositories through npm install in Docker

How do you properly use an SSH key in a Dockerfile? There are many ways to do it, including many ways to do it wrong. What you will want to prevent is that your ssh key ends up in one of your intermediate images or layers. These are the layers that Docker creates with pretty much every command in your Dockerfile. You may think that you properly clean up your secrets later in the Dockerfile, but the secret will then still be available in one of these layers.

Building serverless applications with the AWS CDK - and testing them locally

The AWS Cloud Development Kit (AWS CDK) is a new framework for defining Infrastructure as Code (IaC) by AWS. It allows you to write IaC in a set of different languages. At the moment the following languages are supported: Javascript, Typescript, Python, Java, .NET. Support for other languages is coming. Of course, other methods like CloudFormation and Terraform already exist to write IaC. Using these tools you write declarative code in YAML, JSON or the Hashicorp Configuration Language (HCL) in a mostly declarative state.

Improving Kubernetes deployments with Helm

I recently blogged about automated deployments to Kubernetes using GitLab. One of the steps required when automating deployments is replacing the Docker tag with the correct value in the Kubernetes Deployment. In that blog post, this looks like the following: deployment.yaml apiVersion: apps/v1 kind: Deployment metadata: [...] spec: template: spec: containers: image: sanderknape/go-hello-world:<VERSION> [...] The <VERSION> string is then replaced in the GitLab pipeline as follows: sed -i "s/<VERSION>/${CI_COMMIT_SHORT_SHA}/g" deployment.

Using Kubernetes Helm to push ConfigMap changes to your Deployments

In recent years Kubernetes has quickly gained a lot of popularity and it currently has huge momentum. Adoption is rising while at the same time, new users find out the areas where Kubernetes is still lacking. One such area is the lifecycle management of application configuration. The construct in Kubernetes to store such configuration is the ConfigMap. These ConfigMaps can be referenced from Pods or Deployments and the values can be injected to the container using environment variables or files through volumes.

Automated deployments to Kubernetes with GitLab

In this blog post we’ll go through the steps of creating an automated deployment pipeline for Kubernetes using GitLab. In the end we’ll have a simple Go application running that very excitingly returns “Hello, World!”. Prerequisites Before we can begin our quest for automation, we’ll need to set up some tools. Many alternatives of course exist to the tools that I pick. Feel free to use any other option, but make sure to make any necessary changes if you are following along with this post.

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

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”.

How to easily test your AWS IAM credentials locally

It is still very common to develop an application locally on a laptop/desktop before pushing it to a production-like environment. The local development environment is kept as close as possible to production using technology such as Docker or AWS SAM when working with AWS Lambda. However, when working with AWS resources through Identity and Access Management (IAM) policies, local IAM permissions are typically different from the permissions the application will have in AWS.