Sailing the AWS IaC Seas

Infrastructure as Code is an incredibly valuable solution with a ton of applicable use cases in modern cloud practices. Often times I'm approached to build out solutions from scratch or from existing cloud environments using either CloudFormation (AWS IaC) or Terraform. Both these solutions present benefits in multiple ways and provide companies with the ability to maintain and update existing cloud resources by often adding/changing just a few lines of code. It's a practice that's existed for years, but it's often overlooked as a mandatory skillset upon hiring a "Cloud Professional". This is alarming considering IaC allows for a much faster, more secure, and often times easily auditable trail for compliance purposes. There are also numerous ways you as a professional, or your company should be maintaining IaC to ensure secure deployments of your cloud services. I'm going to go over what I often see as the best approach for either fresh IaC or existing resources in need of IaC templating.

Fresh IaC Deployments:

So, you've architected a service deployment within AWS. You're aware of what services you want to utilize and how said services should communicate. Given this approach your IaC templates should be written on a per service basis whenever possible to allow for easy additions in the future. This also provides value add vs. just building out your resources via the console. Reason being, if the customer or company for which you template ever wants to build out an HA or DR plan in the future, or even move to another region within AWS... They have a solid base to do so. Changing a few services to be "globally" supported and redeploying the stack to a new region performs about 80% of the total leg work needed to make things a reality. If the customer or client wants their IaC native to AWS you can use CloudFormation to provide them with a centralized experience without the need of any 3rd party additions. However, that doesn't mean you shouldn't be performing security scans on the templates themselves prior to deployment. That said, there's often an open source tool for everything https://cloudsploit.com/cloudformation provides an easy way to scan your templates for security related risks prior to deployment to an AWS account. To get started with CloudFormation templates and the depth of resources you can deploy, I'd recommend referencing the existing templates here: https://asecure.cloud/.

So aside from native, there's also Terraform. Terraform allows for building out IaC using what're known as modules, as well as some nice "cloud hosted" features for maintaining access to your IaC repository and even performing test runs when you do update Terraform versions https://www.terraform.io/cloud. In addition to this, there are also numerous tools you can tie into git repositories that perform scans for security misconfigurations such as https://github.com/accurics/terrascan. Terraform provides benefits for those looking to delegate and scale in a more mature fashion. It's also worth noting the real selling point for it is the use of modules. Modules are groups or resources that often interact closely with one another. These allow you to reflect changes within your infrastructure and reconfigure all related ties at once to avoid both misconfigurations and downtime. You can read more about modules here: https://www.terraform.io/docs/language/modules/index.html.

Existing Resources:

Clients often approach me with a pre-existing environments and want their cloud environment "modernized". This often involves template generation for currently utilized cloud resources. There have been multiple implementations of how to perform this process as it is an ongoing need. One of the earliest examples for CloudFormation template generation is CloudFormer: https://aws.amazon.com/blogs/devops/building-aws-cloudformation-templates-using-cloudformer/. CloudFormer was a great first step in an attempt to meet the need for easy templating. However, generating things in JSON and converting to YAML isn't a fun time. It's also not great when you have to select every individual resource within a service because it doesn't account for underlying service dependencies. But hey, you get the picture...

This lead me down a path of trying to locate a better overall solution for both myself and newcomers to utilize and ultimately I ended up with Former 2: https://former2.com/. Former2 speeds up the process quite a bit by performing scans of all resources within an account by using the AWS CLI. You then select the resources you want to generate a template for and it presents you with a template. It also covers much more of the AWS ecosystem as it's an actively maintained solution. So, if you're building CloudFormation and want something with ease-of-use in mind. This is exactly the solution you want.

Again, we'll cover Terraform but purely from the generation of .tf  files for pre-existing AWS resources. The methods used below are by far the easiest and provide you with additional use cases for both deploying to new regions within AWS, or within other AWS accounts. You'll need both the AWS CLI, and a terraform install to proceed with this process. When presented with the task of generating Terraform by service simply utilize: http://terraforming.dtan4.net/. Terraforming generates files per service layer for your account. Although you may need to make changes if you're attempting to use the latest tf version in order to pass the syntax properly. It's important to note that in order to use the generated files with an existing account against active resources, you'll also need to generate a tfstate file which can be done using using terraforming as well per the documentation. Otherwise you'd need to import each resource using the 'terraform import' command. Hashicorp has stated they'll be adding a mass import function in a later version at the time of this writing.