The Ultimate Infrastructure as Code Guide: Accelerating Modern Cloud Operations
When provisioning and managing compute resources, application environments, and data storage for your applications, you and your engineering teams spend way too much time provisioning and managing compute resources, application environments, and data storage for your applications.
Automating the tasks of manual infrastructure management can be achieved with the use of IaC (Infrastructure as Code). This allows for the entire IT infrastructure to be defined, provisioned and managed by using machine-readable definition files.
This guide to Infrastructure as Code for infrastructure architects, engineers, and developers will help you scale fast-growing startups as well as modernize and develop enterprise-grade systems and applications using the latest architectures, use cases, tools, and strategies for a number of programming languages.
What is infrastructure as code?
In summary, Infrastructure as Code (IaC) means managing and provisioning the computing infrastructure (e.g. servers, networks, load balancing, databases, and clusters of servers, including Kubernetes clusters) by using definition files written as code. Unlike managing and provisioning IT computing infrastructure by human interaction with a graphical user interface or by other than coding processes, managing and provisioning computing IT infrastructure as code means managing and provisioning IT computing infrastructure as code.
Manually managing environments to test different scenarios for your application can take up a large amount of a system administrator’s time. Managing multiple versions of environments can be a complex and frustrating process for administrators and developers.
+-------------------+ +-------------------+ +-------------------+
| Version Control | ----> | IaC Engine | ----> | Cloud Provider |
| (GitHub/GitLab) | | (Terraform/Pulumi)| | (AWS/Azure/GCP) |
| .tf / .yaml | | Plan & Apply | | Provisioned Infra |
+-------------------+ +-------------------+ +-------------------+
For IaC, you would set up your cloud infrastructure in your preferred language, stored in your version control system, such as Git. So, when your application needs a new database, for example, you would write a few lines of code, go through a pull request with your team, and then run through an automated deployment.
Declarative vs. Imperative Infrastructure as Code
You learn here how to differentiate between declarative and imperative approaches. This is fundamental when you compare different IaC frameworks.
Declarative Approach (What you want): You define the end state of your server infrastructure; IaC will then compute the differences between the current state and your end state and apply these differences as changes to your current state. Examples of such tools are HashiCorp Terraform and AWS CloudFormation.
Imperative Approach (How to do it): This type of approach involves a developer writing a script or program that explains step by step how to achieve a desired configuration. The programs can be very complex and are typically very difficult to maintain as environments evolve.
The Strategic Role of Infrastructure as Code for DevOps
While Continuous Integration / Continuous Delivery (CI/CD) pipelines enable fast application software delivery, server infrastructure cannot scale at the same pace and therefore acts as a bottleneck.
However, deploying software in DevOps teams is slowed down by server infrastructure that cannot scale at the same pace. In order to speed up deployment, software developers and system operators have to work together to set up server infrastructure for development, testing, and production. This is where implementing Infrastructure as Code (IaC) for DevOps really kicks in.
+-----------------------------------+
| Continuous Integration |
| (Linting, Validation, Security) |
+-----------------------------------+
|
v
+------------------+ +-------------------+ +-------------------+
| Developer Writes | ---> | Pull Request Code | ---> | Automated Deploy |
| IaC Definitions | | Peer Review | | Staging & Prod |
+------------------+ +-------------------+ +-------------------+
Core Business & Technical Advantages
- Removes Environment Drift: Environment drift can be caused by unrecorded manual changes to a staging or production server. IaC code is used to generate dev, test and production environments from identical source code files.
- Quick provisioning of the cloud-based multi-region enterprise cloud infrastructure that typically would take weeks to set up can now be set up in minutes through automated pipeline execution.
- Disaster Recovery and Traceability: Even when a single cloud region goes down, IaC code is used to deploy the complete stack to another region within minutes. Version control history is used to create a complete audit trail of all changes to the code, including who made changes, when the changes were made, and why the changes were made.
- Save costs: Automated scripts can tear down your environments for development, testing and staging outside of working hours and prevent costs for idle resources.
Evaluating the Top Infrastructure as Code Tools
There are many great tools in the market for IaC, each having their own strengths and weaknesses. In this article, we will evaluate the top IaC tools available today. The choice of the tool depends on several parameters including the technical stack, programming skills and requirements for multi-cloud support.
Tool
Approach
Primary Language
Cloud Provider Compatibility
Best Suited For
HashiCorp Terraform
Declarative
HCL (HashiCorp Configuration Language)
Multi-cloud (AWS, Azure, GCP, On-prem)
Heterogeneous multi-cloud environments
AWS CloudFormation
Declarative
JSON / YAML
AWS-centric
AWS-native ecosystems seeking zero setup
Pulumi
Declarative / Imperative
TypeScript, Python, Go, C#, Java
Multi-cloud
Developer teams preferring general-purpose languages
Ansible
Imperative / Declarative
YAML
Multi-cloud / OS Configuration
Configuration management and server provisioning
OpenTofu
Declarative
HCL
Multi-cloud
Open-source alternative to Terraform
1. HashiCorp Terraform
HashiCorp Terraform is still the de facto standard for provisioning multi-cloud infrastructure. It uses the HashiCorp Configuration Language (HCL) to manage state files for cloud resources and supports hundreds of different providers.
2. Pulumi
Pulumi supports writing your infrastructure in familiar programming languages, such as TypeScript, Python, Go, and C#. Because of this, Pulumi supports development in IDEs, with tools such as auto-completion, unit testing, and, more importantly, full object-oriented design.
3. AWS CloudFormation & OpenTofu
AWS CloudFormation is a very powerful tool to manage your AWS resources, as it’s natively integrated for all of them. It does not require any external state management storage. OpenTofu, an open-source project forked from Terraform and managed by the Linux Foundation, is an alternative to Terraform, which is open source as well and might be of interest to you and your organization.
A Practical Infrastructure as Code Tutorial: Provisioning AWS Resources with Terraform
Here’s an example of practical IaC with an infrastructure as code tutorial. This tutorial is for a declarative Terraform configuration. This tutorial covers the creation of a safe AWS S3 bucket by using server-side encryption and storing versioned copies of the bucket’s configuration.
Prerequisites
- Terraform CLI installed locally.
- An active AWS account with configured AWS CLI credentials (aws configure).
Step 1: Define the Provider Configuration
Create a new directory on your machine and create a file named main.tf. We begin by specifying our cloud provider and target cloud region:
Terraform
# main.tf
terraform {
required_version = ">= 1.5.0"
required_providers {
aws = {
source = "hashicorp/aws"
version = "~> 5.0"
}
}
}
provider "aws" {
region = "us-east-1"
}
Step 2: Define Infrastructure Resources
Next, append the resource definitions to create an isolated Amazon S3 bucket with strict security settings and versioning enabled:
Terraform
# Create a unique S3 bucket for application assets
resource "aws_s3_bucket" "app_assets" {
bucket = "my-company-app-assets-production-2026"
force_destroy = false
tags = {
Environment = "Production"
ManagedBy = "Terraform"
Project = "IaC-Guide"
}
}
# Enable Object Versioning
resource "aws_s3_bucket_versioning" "assets_versioning" {
bucket = aws_s3_bucket.app_assets.id
versioning_configuration {
status = "Enabled"
}
}
# Apply Default Server-Side Encryption
resource "aws_s3_bucket_server_side_encryption_configuration" "assets_encryption" {
bucket = aws_s3_bucket.app_assets.id
rule {
apply_server_side_encryption_by_default {
sse_algorithm = "AES256"
}
}
}
Step 3: Initialize, Plan, and Deploy
Open your terminal inside the project folder and execute the three standard IaC commands:
- Initialize the workspace: Downloads necessary provider plugins.
- Bash
terraform init
- Preview proposed infrastructure changes: Shows exactly what resources will be created before touching your live cloud environment.
- Bash
terraform plan
- Apply changes to AWS: Provisions the real-world infrastructure on AWS.
- Bash
terraform apply
Within seconds, Terraform contacts the AWS API, provisions your S3 bucket according to your precise parameters, and saves the current state to a state tracking file.
Battle-Tested Infrastructure as Code Best Practices
The above best practices for IaC can be easily written, but harder to maintain for a large enterprise infrastructure, requiring strict engineering practices.
1. Store State Files in Secure, Remote Storage
Don’t store local state files in version control (i.e. in Git repositories). Local state files often contain sensitive metadata as well as secret text data (e.g. passwords, API keys, etc). Instead store state files in secure remote storage using (for example) AWS S3 with DynamoDB state locking, HashiCorp CloudPlatform, or Azure Blob Storage.
2. Implement Immutable Infrastructure
In general, it’s best to avoid logging into a newly created instance of a Virtual Machine (VM) and hand updating the configuration. Instead, update the source Infrastructure as Code (IaC) files, delete the existing instances, and then provision a new group of instances with the updated configuration. This results in zero configuration drift.
3. Modularize Your Code Architecture
Divide and conquer! Instead of having one big configuration file for all your infrastructure, split it up into separate modules for the different areas of your infrastructure. These can be for example a networking module, a database module, a security module, etc.
4. Integrate Static Code Analysis and Policy-as-Code
Prior to applying updates to code, perform security scanning. With tools like Checkov, tfsec and Trivy, you can immediately analyze your IaC scripts for any possible misconfigurations, e.g., open database ports, unencrypted storage buckets, etc. Use this in your CI/CD pipeline.
Pro Security Tip: Utilize Policy-as-Code tools such as Open Policy Agent (OPA), AWS CloudFormation Guard and others to automatically block devops pull requests that don’t follow your company’s security compliance policies.
Common Pitfalls to Avoid in IaC Projects
In summary, transitioning to Infrastructure as Code (IAA) is a major cultural and technical change for most organizations. The following describes common pitfalls in developing IAA projects.
IaC is not about setting up lots of shell scripts to manage and configure your cloud-based infrastructure. Rather, it’s about using software design principles to create modular IaC scripts that follow the DRY principle (Don’t Repeat Yourself).
Bypassing Version Control for "Quick Fixes" and subsequent problems in the cloud: IaC is about code and thus subject to version control like any other piece of code. Ad hoc changes in the cloud provider’s console are soon going to diverge from automated deployments and cause problems.
Bad Practices – Ignore RBAC & Secrets Management: Never hardcode database passwords or AWS secret keys inside your IaC scripts. Fetch secret keys dynamically from dedicated tools like HashiCorp Vault, AWS Secrets Manager or Azure Key Vault at runtime.
Transform Your Cloud Strategy with Industry Experts
A robust, scalable and secure Infrastructure as Code (IaC) framework requires specialized knowledge to set up an automated enterprise CI/CD pipeline. It also requires refactoring of current cloud architectures into secure Terraform or Pulumi modules to run these in production. Our experienced DevOps engineers are here to support you.
We create custom-designed infrastructure for optimal performance, scalability, and cost efficiency. Our consulting work consists of cloud migrations, security audits and more.
Need Help Modernizing Cloud Operations? The DevOps Engineering team at InterGart is here to help you deploy and operate your cloud-based application or system in a scalable, highly available, and cost-efficient manner while eliminating the need for manual deployments. We perform architecture reviews and design and implement IaC solutions. Contact us today.
Got Questions? Here Are Some FAQs
1: What is the main difference between configuration management and IaC?
In terms of main functionality, the Infrastructure as Code (IaC) tools Terraform and CloudFormation manage cloud-based infrastructure. That means, for example, virtual networks, servers, databases and storage. Configuration Management on the other hand (which can also be implemented using IaC tools) deals with the installation and configuration of software. So in effect it deals with the packages of a server and the OS settings of that server. In order to do effective DevOps, both of these approaches are used today.
2: Is Infrastructure as Code only useful for cloud platforms?
No. While IaC is mostly used in public cloud platforms like AWS, Microsoft Azure and Google Cloud, it can also be used to manage private clouds, on-premises servers and hypervisors like VMware vSphere, OpenStack and Nutanix. There are API’s and providers for each of these environments.
3: How does IaC handle sensitive secrets like database passwords?
Secrets in IaC should not be hardcoded in definition files. Instead, definition files reference external secrets management services (e.g. AWS Secrets Manager, HashiCorp Vault, Azure Key Vault) or deployment environment passes in encrypted environment variables while deploying.
4: What happens if an infrastructure change fails halfway through a deployment?
There are many modern IaC engines, which use state management and provide transactional APIs to manage the state of resources during deployment. These IaC engines track the progress of a deployment. If the deployment fails halfway through, the IaC engine will report which resources have been successfully provisioned and which resources have not been provisioned successfully. After fixing the problem, you can then safely run an apply command to complete the provisioning of the remaining resources.
5: How do I choose between Terraform and Pulumi for your team?
Terraform is better suited for teams that prefer to work with a mature, standard declarative language (HCL) for their infrastructure configuration, and have access to a huge community, and plenty of plugins for all sorts of edge cases. Pulumi is better for teams composed largely of software developers who manage infrastructure using programming languages (TypeScript, Python, Go) that have existing testing and abstraction for that kind of work.
SevenMentor
Expert trainer and consultant at SevenMentor with years of industry experience. Passionate about sharing knowledge and empowering the next generation of tech leaders.