Hello all!
Welcome to the next issue of the Tidy Cloud AWS bulletin! In this issue we have a walkthrough of Terraform extension for VS Code, some AWS Blogs, picking a language for your infrastructure-as-code, or perhaps pick languages - there is not a one-size-fits-all, more likely. And finally, a video introduction to CDK for Terraform (CDKTF), which was made GA some time ago.
Enjoy!
Terraform extension in Visual Studio Code
Recently Hashicorp published a video session where they were showing the Hashicorp Terraform extension in Visual Studio Code. The extension itself has mixed reviews. It was originally a 3rd party extension which Hashicorp took over maintenance for.
Personally I have been using Anton Kulikov’s Terraform extension, partially because it has Terragrunt support as well. This video highlighted a few features though that I thought interesting in terms of navigation of code and documentation, as well as formatting, which I thought useful.
One advantage of using a regular programming language is that there is often better support in various tools to improve the workflow when authoring code in that language, compared to general configuration formats or domain specific languages. The Terraform extensions for Visual Studio Code bridges that gap somewhat and is a step in the right direction.
AWS Blog posts of interest
AWS employees produce a lot of blog posts, there are many posts each day at AWS Blogs home. You need to filter out based on category to cut it down to what may be most interesting. Here are a few that may be of interest:
One blog post illustrates the use of CloudFormation custom resources in combination with AWS Step Functions to support infrastructure-as-code deployments for resources not supported by CloudFormation that can take a long time to deploy (over 15 minutes).
Another post covers consistent tagging for cost tracking, although it is focused on the use of AWS Proton and is perhaps a way to promote that service.
AWS Proton is a service to provide some automation, pipelines and self-service for infrastructure-as-code templates, for function-as-a-service and containerized solutions. It supports CloudFormation and Terraform.
I have honestly some mixed feelings about Proton. It is nice that AWS tries to provide additional tools in this space, but it is also one of many efforts from AWS to provide more tools for automation and self-service of different workloads - which often seem to be developed independently of each other.
Infrastructure as code drift detection
There are two blog posts that try to cover different aspects of detecting configuration drift in cloud resources.
One approach is to collect a report on daily changes of resource configurations. The report is sent by email. This solution does not require any infrastructure-as-code solution in place, it only tracks resource changes overall. It may be more useful if you do not already have a well-defined infrastructure-as-code solution in place and want to get some understanding of what is changing in your environment. The example implementation uses Python with AWS CDK.
I found the implementation slightly unusual because it uses CloudFormation parameters in combination with AWS CDK, which is not what you would typically use when parametrising AWS CDK solutions. However, my guess is that the aim may be to use the generated CloudFormation directly for places in which AWS CDK is not used.
Another blog post covers automatically detecting drift in CloudFormation stacks, thus assuming that you have an infrastructure-as-code solution in place based on CloudFormation.
What both posts have in common is that they can use AWS EventBridge to collect data from multiple accounts to provide centralized notification of drift/changes.
This is an increasingly common pattern and not just for configuration changes, but for many types of collection of data from multiple accounts into a centralized location.
Serverless Jenkins
Jenkins is a quite common Continuous Integration solution, which typically has been deployed on multiple servers. Nowadays there are also many SaaS solution to provide similar capability. Still, Jenkins is used in many places, for various reasons. To move Jenkins off the dedicated servers, this blog post illustrates an approch to deploy Jenkins as a containerized solution, using AWS CDK.
Control Tower infrastructure as code
AWS Control Tower is a useful service for setting up a multi-account solution for your AWS workloads, with some baseline components put in place which makes life easier to manage the complexity behind a multi-account solution.
However, so far there has been no way to handle Control Tower specific operations programmatically you have to use ClickOps. Which is bad.
This has changed now however, and there is now at least a bit more exposed for programmatic use, which includes defining which guardrails should be enabled on each account managed by Control Tower.
Choosing a language for infrastructure as code
I recently published an article on choosing a language to use for infrastructure as code. You can find many places where people argue for using programming languages, and other for using more declarative languages, like HCL, YAML or CUE.
There are valid cases for both, and I try to outline some considerations for when you may pick one over the other. Check it out!
CDKTF intro
Hashicorp published an intro video session for CDK for Terraform when it became generally available. I found it useful from a perspective of a person who is familiar with regular Terraform, and also AWS CDK, but has not used CDKTF that much.
You can find the contents of this bulletin and older ones, and more at Cloudgnosis.org. You will also find other useful articles around AWS automation and infrastructure-as-software.
Until next time,
/Erik