Skip to content

DevOps Day 94: Create VPC Using Terraform

This document outlines the solution for DevOps Day 94. The objective was to provision a fundamental networking component—an AWS Virtual Private Cloud (VPC)—using Infrastructure as Code (IaC) with Terraform.

Table of Contents

Task Overview

Objective: Provision an AWS VPC named nautilus-vpc in the us-east-1 region using Terraform.

Requirements: 1. Directory: /home/bob/terraform 2. File: Create only main.tf. 3. Resource: aws_vpc 4. Properties: * Name Tag: nautilus-vpc * CIDR Block: Any valid IPv4 CIDR (e.g., 10.0.0.0/16). * Region: us-east-1.

Step-by-Step Solution

1. Create the main.tf File

This file contains the provider configuration (telling Terraform where to create resources) and the resource definition (telling Terraform what to create).

Command: 

cd /home/bob/terraform
vi main.tf

Content: 

provider "aws" {
  region = "us-east-1"
}

resource "aws_vpc" "main" {
  cidr_block = "10.0.0.0/16"

  tags = {
    Name = "nautilus-vpc"
  }
}

2. Initialize Terraform

Before Terraform can do anything, it needs to download the code that knows how to talk to AWS. This is the AWS Provider.

Command: 

terraform init
* Output: "Terraform has been successfully initialized!" * What happened: Terraform scanned main.tf, saw provider "aws", and downloaded the AWS plugin into a hidden .terraform/ directory.

3. Generate the Plan

This is a dry run. Terraform compares your main.tf against the current state of your AWS account (which is empty right now).

Command: 

terraform plan
* Output: Plan: 1 to add, 0 to change, 0 to destroy. * Analysis: Terraform calculates that to match your code, it needs to create one new VPC.

4. Apply the Configuration

This executes the plan and actually talks to the AWS API to create the resource.

Command: 

terraform apply
* Prompt: Type yes when asked. * Output: Apply complete! Resources: 1 added, 0 changed, 0 destroyed.

Deep Dive: How Terraform Works Internally

You asked how Terraform talks to cloud providers and creates infrastructure. Here is the breakdown of the magic under the hood.

Core Architecture

Terraform is split into two main parts: 1. Terraform Core: The binary you download (terraform). It reads your configuration files (.tf) and manages the State. It essentially builds a dependency graph of your resources (e.g., "I need a VPC before I can create a Subnet"). 2. Providers: These are separate plugins (like the AWS Provider, Azure Provider, Google Provider) that act as translators.

The Provider Plugin Model

Terraform Core doesn't know what an AWS VPC is. It just knows "resource aws_vpc". * When you run terraform apply, Core passes the configuration data to the AWS Provider Plugin. * The Provider's Job: The AWS Provider is written in Go and contains the AWS SDK. It translates the Terraform configuration (cidr_block = "10.0.0.0/16") into an actual AWS API Call (e.g., ec2:CreateVpc). * Authentication: The provider handles the authentication using the credentials stored in your environment (~/.aws/credentials or environment variables) to sign these API requests securely.

State Management (terraform.tfstate)

This is Terraform's brain. * When you created the VPC, AWS returned an ID (e.g., vpc-01234567). * Terraform must remember this ID. If it forgets, running terraform apply again would create a second VPC instead of updating the first one. * It saves this mapping (Resource Name aws_vpc.main -> Real ID vpc-01234567) in a JSON file called terraform.tfstate.

Execution Flow

1. Read Config: Terraform reads main.tf. 2. Refresh State: It checks terraform.tfstate and queries the real AWS API to see if the resources still exist. 3. Diff: It compares Config vs. Real World. * Config says: VPC exists with CIDR 10.0.0.0/16. * Real World says: Nothing exists. * Result: Create (+). 4. Execute: It calls the AWS Provider -> AWS Provider calls AWS API (CreateVpc) -> AWS creates the VPC. 5. Update State: AWS returns the new VPC ID. Terraform writes this into terraform.tfstate.