Apply these best practices to get the most out of your IaC efforts.

This is the second post in our series on Infrastructure as Code. Check out our first post, Infrastructure as Code: 5 Reasons Why You Should Implement IaC Now, and click here to sign up to be notified of future posts.

In our first post about Infrastructure as Code, we highlighted the five primary benefits of automating your infrastructure deployments with IaC. In this post, we’re going to identify some best practices that can be implemented so you can get the most out of IaC.

These best practices include:

  1. Codify everything
  2. Document as little as possible
  3. Maintain version control
  4. Continuously test, integrate, and deploy
  5. Make your infrastructure code modular
  6. Make your infrastructure immutable (when possible)

Let’s dig in.

Infrastructure as code best practices

1) Codify everything

What would Infrastructure as Code be without the “code” part?

All infrastructure specifications should be explicitly coded in configuration files, such as AWS CloudFormation templates, Chef recipes, Ansible playbooks, or any other IaC tool you’re using (more info about IaC tools to come in a future article – click here to receive future updates).

These configuration files represent the single source of truth of your infrastructure specifications and describe exactly what cloud components you’ll use, how they relate to one another, and how the entire environment is configured.

Infrastructure can then be deployed quickly and seamlessly, and ideally no one should log into a server to manually make adjustments.

Codify all the infrastructure things!

2) Document as little as possible

Your IaC code will essentially be your documentation, so there shouldn’t be many additional instructions for your IT employees to execute.

In the past, if any infrastructure component was updated, documentation needed to be updated in lockstep to avoid inconsistencies. We know that this didn’t always happen.

With IaC, the code itself represents the documentation of the infrastructure and will always be up to date. Pretty powerful, huh?

Additional documentation, such as diagrams and other setup instructions, may be necessary to educate those employees who are less familiar with the infrastructure deployment process. But most of the deployment steps will be performed by the configuration code, so this documentation should ideally be kept to a minimum.

3) Maintain version control

These configuration files will be used version-controlled. Because all configuration details are written in code, any changes to the codebase can be managed, tracked, and reconciled.

Just like with application code, source control tools like Git, Mercurial, Subversion, or others should be used to maintain versions of your IaC codebase. Not only will this provide an audit trail for code changes, it will also provide the ability to collaborate, peer-review, and test IaC code before it goes live.

Code branching and merging best practices should also be used to further increase developer collaboration and ensure that updates to your IaC code are properly managed.

4) Continuously test, integrate, and deploy

Continuous testing, integration, and deployment processes are a great way to manage all the changes that may be made to your infrastructure code.

Testing should be rigorously applied to your infrastructure configurations to ensure that there are no post-deployment issues. Depending on your needs, an array of test types – unit, regression, integration and many more – should be performed. Automated tests can be set up to run each time a change is made to your configuration code.

Security of your infrastructure should also be continuously monitored and tested. DevSecOps is an emerging practice where security professionals work alongside developers to continuously incorporate threat detection and security testing throughout the software development life cycle instead of just throwing it in at the end.

By increasing collaboration between testing, security, and development, bugs and threats can be identified earlier in the development life cycle and thus minimized upon going live.

With a sound continuous integration process, these configuration templates can be provisioned multiple times in different environments such as Dev, Test, and QA. Developers can then work within each of these environments with consistent infrastructure configurations. This continuous integration will mitigate the risk of errors being present that may detrimental to your application when the infrastructure is deployed to production.

5) Make your infrastructure code modular

Microservices architecture, where software is built by developing smaller, modular units of code that can be deployed independently of the rest of a product’s components, is a popular trend in the software development world

The same concept can be applied to IaC. You can break down your infrastructure into separate modules or stacks then combine them in an automated fashion.

There are a few benefits to this approach.

First, you can have greater control over who has access to which parts of your infrastructure code. For example, you may have junior engineers who aren’t familiar with or don’t have expertise of certain parts of your infrastructure configuration. By modularizing your infrastructure code, you can deny access to these components until the junior engineers get up to speed.

Also, modular infrastructure naturally limits the amount of changes that can be made to the configuration. Smaller changes make bugs easier to detect and allow your team to be more agile.

And if you use the microservices development approach, a configuration template can be created for each microservice to ensure infrastructure consistency. Then all of the microservices can be connected through HTTP or messaging interfaces.

If you’d like to learn more about modularized Infrastructure as Code, check out this Slideshare.

6) Make your infrastructure immutable (when possible)

The idea behind immutable infrastructure is that IT infrastructure components are replaced for each deployment, instead of changed in-place.

You can write code for and deploy an infrastructure stack once, use it multiple times, and never change it. If you need to make changes to your configuration, you would just terminate that stack and build a new one from scratch.

Making your infrastructure immutable provides consistency, avoids configuration drift, and restricts the impact of undocumented changes to your stack. It also improves security and makes troubleshooting easier due to the lack of configuration edits.

While immutable infrastructure is currently a hotly-debated topic, we believe that you should try to make your infrastructure immutable whenever possible to increase the consistency of your configurations.


Infrastructure as Code can provide many benefits such as consistency, speed of deployment, simplicity, and more. And if you follow these best practices, you’ll get the most out your IaC deployments.

Stay tuned for our next post in this series on Infrastructure as Code. To be notified of future posts, sign up below.

Like this post? It likes you too. Please share it using the share buttons to the left. Then join our mailing list below, follow us on Twitter @thorntech, and join our Facebook page for future updates.