Learn Cloud Computing - Infrastructure as Code (IaC) & Cloud Automation

#Introduction

After episode 15, where we built full oversight over the system, this time we attack the root problem that has always haunted manually built infrastructure: the inability to reproduce it. A system that can't be rebuilt identically isn't a system — it's just a one-off artifact that was never truly understood.

This episode covers why infrastructure must be written as code, the native tools each cloud provides, and the agnostic multi-cloud approaches with Terraform, OpenTofu, and Pulumi. By the end of the episode, you'll see infrastructure the way a senior engineer does: as code that can be reviewed, tested, and rolled back.

#Main Discussion

#Why IaC: Fighting ClickOps

ClickOps — building infrastructure through console clicks — feels fast and easy, but hides four chronic problems:

1. Not reproducible — no two click sessions are exactly the same; you'll never be sure the staging environment is identical to production.
2. Not documented — configuration lives in the engineer's head; when they leave the team, the knowledge leaves with them.
3. Not auditable — there's no trace of who changed what and when, making incidents hard to trace.
4. Prone to human error — console menus change every release, and one wrong click can cost a lot.

Infrastructure as Code (IaC) answers all four by treating infrastructure like application code: written in files, stored in version control, reviewed via pull requests, and deployed repeatedly. The analogy is a cooking recipe: a chef who only memorizes in his head can't pass on his skill, while a written recipe can produce the same taste in a hundred different kitchens.

There are two paradigms you must distinguish: imperative states the sequence of steps — create the VPC first, then the subnets, then the routes — while declarative only states the end state: "I want this VPC and that subnet" — the tool takes care of the steps. Modern clouds favor declarative because it's idempotent: running the same configuration repeatedly produces the same state, with no side effects.

#The Big 3 Native Tools

Each cloud provides a native IaC tool, most appropriate if you're committed to a single provider:

• AWS CloudFormation — uses YAML or JSON. A group of resources is declared in one template and managed as a single unit called a stack.
• GCP Cloud Deployment Manager — uses YAML, with Python and Jinja support for more dynamic templates.
• Azure ARM Templates — JSON-based; Bicep is a more concise declarative language that compiles into ARM templates.

An example CloudFormation template for a single web instance:

AWSTemplateFormatVersion: '2010-09-09'
Description: Web server sederhana
 
Resources:
  WebServer:
    Type: AWS::EC2::Instance
    Properties:
      InstanceType: t3.micro
      ImageId: ami-0abcdef1234567890
      SecurityGroupIds:
        - sg-0a1b2c3d4e5f67890
      Tags:
        - Key: Name
          Value: web-server-01

This file can be committed to git, deployed with one command, and removed with one command too — the entire stack, not resources one by one. Changes are made simply by editing the file and re-deploying; CloudFormation calculates the difference between the current state and the desired one.

#Multi-Cloud Agnostic: Terraform, OpenTofu, and Pulumi

Many teams work across clouds or move between providers. For that need, there are agnostic tools not tied to a single cloud:

• Terraform — the HCL language, the most popular tool in its class. It has official providers for AWS, GCP, Azure, and thousands more, so one language for all clouds.
• OpenTofu — the open source fork of Terraform (MPL license) compatible with Terraform configuration, the choice for organizations wanting a pure open source license.
• Pulumi — uses general-purpose programming languages like TypeScript, Python, or Go, suitable for teams more comfortable writing code than a special DSL.

The key to Terraform is the state file: a record of the resources already created. Every time you run a command, Terraform compares the desired configuration with the state, then composes a plan of changes. The basic workflow:

terraform init      # download the required providers
terraform plan      # create a change plan, without applying
terraform apply     # apply the plan to the cloud
terraform destroy   # remove all managed resources

Before applying anything, run terraform plan first. That command produces a summary of how many resources will be added, changed, and deleted — the last chance to inspect before changes actually execute. This small habit saves production from accidental deletion.

#Reading a Plan Result

The output of terraform plan speaks through three symbols you must understand:

Terraform used the selected providers to generate the following execution plan.
 
  # aws_instance.web will be updated in-place
  ~ resource "aws_instance" "web" {
      ~ instance_type = "t3.large" -> "t3.medium"
        tags          = { "Name" = "web-server-01" }
    }
 
  # aws_security_group.allow_https will be created
  + resource "aws_security_group" "allow_https" {
      + name        = "allow-https"
      + description = "Allow inbound HTTPS"
    }
 
Plan: 1 to add, 1 to change, 0 to destroy.

• The + symbol means a new resource to be created.
• The ~ symbol means an existing resource to be changed.
• The - symbol means a resource to be deleted.

The last line summarizes everything. Before pressing apply, you only need to ask one question: is what's being deleted or changed really what you intended? That simple question saves production more often than you'd think.

#Advanced Automation Patterns

IaC opens the door to larger patterns:

• CI/CD for infrastructure — a pipeline in GitHub Actions or GitLab CI that runs terraform plan on every pull request, then terraform apply after it's approved and merged.
• Enforcement — putting rules (for example, a minimum instance size, or a ban on open ports) in the pipeline so deviations are rejected before they reach the cloud.
• Centralized state — storing state in a remote backend (S3, GCS, Azure Storage) with locking, so teams can work together without conflicts.

#Conclusion

In this episode 16 you learned the foundation of modern infrastructure: the why of IaC — fighting ClickOps for systems that are reproducible, documented, and auditable; the declarative and idempotent paradigm; native tools — CloudFormation, Deployment Manager, and ARM/Bicep for single-cloud teams; and agnostic tools — Terraform, OpenTofu, and Pulumi for multi-cloud teams. You also got to know the plan-before-apply workflow and advanced automation patterns like infrastructure CI/CD and centralized state.

But automation that makes creating resources as easy as breathing has a dark side: cost. The same ease can balloon a bill overnight — environments forgotten to be turned off, instances that are too large, and storage that's never archived. The next episode, FinOps, Cost Management & Cloud Optimization, teaches you to control this one side — because a cost-efficient cloud is as important as an automated one.