---

Imagine having to click through the AWS console hundreds of times to set up a server, a network, and a database, only to realize at the end that you missed a single, crucial checkbox. If you need to replicate that exact setup for a staging environment, you have to do it all over again.

Manual infrastructure is slow, error-prone, and nearly impossible to replicate perfectly. This is where Terraform and Amazon EKS (Elastic Kubernetes Service) come in.

In this post, we are going back to basics. By the end of this article, you will understand what Terraform and EKS actually are, how they work together, and how to read the .tf and .yaml configuration files you will see throughout the rest of this blog series.

Follow along! You can find all the code from this blog series in this GitHub repository: S1R15H/EKS_Project.

Conceptual Overview: Blueprints and Fleet Commanders

Before looking at any code, let’s understand the two core technologies we are dealing with.

What is Terraform?

Think of Terraform like a blueprint for a house. In the old days of cloud computing, you were the builder: you went to the AWS console, bought the “bricks,” and put them together manually.

Terraform changes this. Instead of building the house yourself, you write a detailed blueprint (your Terraform code). You then hand this blueprint to a general contractor (the Terraform engine). The contractor reads your blueprint, looks at the empty lot (your AWS account), and builds the house exactly as you specified. If you later update the blueprint to add a garage, the contractor looks at the existing house, sees it’s missing a garage, and only builds the new addition. This concept is called Infrastructure as Code (IaC).

What is EKS (Elastic Kubernetes Service)?

To understand EKS, you first need to understand Kubernetes. Imagine you are running a global shipping company with thousands of cargo ships (your application containers). Managing where each ship goes, ensuring they have enough fuel, and replacing them if they sink is a logistical nightmare. Kubernetes is the master control system that automates all of this.

However, setting up the Kubernetes control system itself is notoriously difficult. Amazon EKS is AWS’s managed Kubernetes service. Essentially, AWS says, “We will handle the complicated control room and the master dispatchers (the Control Plane). You just provide the cargo ships and the docks they park at (the Worker Nodes).”

Terraform is the tool we use to tell AWS to set up that EKS control room and the surrounding network.

Implementation Deep Dive: Reading the Code

Let’s look at the actual code used to build this infrastructure. We use two main languages: HashiCorp Configuration Language (HCL) for Terraform, and YAML for Kubernetes.

The Anatomy of a Terraform (.tf) File

Terraform files always end in .tf. They are written in HCL, which is designed to be human-readable. Let’s break down the three most important types of blocks you will encounter.

1. The Provider Block

Before Terraform can build anything, it needs to know where to build it. A provider is like a plugin that teaches Terraform how to talk to a specific cloud’s API.

Here is an example from our project’s 1-providers.tf file:

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

• Why it’s written this way: This simply tells Terraform, “We are building in Amazon Web Services, and we want to put our resources in the Ohio data center region (us-east-2).” Without this, Terraform wouldn’t know how to authenticate with AWS or where to route your requests.

2. The Resource Block

The resource block is the most important part of Terraform. It tells Terraform to actually create something in the real world.

Here is a snippet from our 2-vpc.tf file where we create a Virtual Private Cloud (a private network):

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

    enable_dns_support   = true
    enable_dns_hostnames = true

    tags = {
        Name = "staging-main"
    }
}

• Syntax Breakdown: resource is the block type. "aws_vpc" is the specific type of AWS resource we want to create. "main" is our own internal name for this block so we can reference it elsewhere in our code.
• Why it’s written this way: Inside the curly braces {} are the arguments. We pass the IP address range (cidr_block), enable DNS features required by EKS, and attach a Name tag so we can easily identify the network in the AWS console.

3. The Data Block

Sometimes you need to read information from AWS about something that already exists, rather than creating something new. This is what a data block is for.

From our 1-providers.tf:

data "aws_caller_identity" "current" {}

• Why it’s written this way: This block asks AWS, “Who am I currently logged in as?” We can later use this block to dynamically grab the AWS Account ID of whoever is running the Terraform code, ensuring the code works for any team member without hardcoding account numbers.

The Anatomy of a Kubernetes (.yaml) File

Once Terraform builds the EKS cluster, we switch to Kubernetes YAML files to deploy our actual applications. YAML relies entirely on spaces and indentation to structure data.

Here is a simple Kubernetes Service definition:

apiVersion: v1
kind: Service
metadata:
  name: myapp
spec:
  type: LoadBalancer
  ports:
    - port: 8080
      targetPort: http

• Why it’s written this way: kind tells Kubernetes what object to create (a Service). The metadata gives it a name. The spec (specification) defines how it should behave—in this case, acting as a LoadBalancer that listens on port 8080.

Gotchas and Practical Tips

If you are just starting out with Terraform and EKS, keep these two critical warnings in mind:

1. Never delete your terraform.tfstate file. When Terraform builds your blueprint, it records exactly what it created in a hidden file called the state file. If you delete or manually alter this file, Terraform will lose track of your AWS resources. It will think the lot is empty and might try to build a second house on top of your first one!
2. YAML is strictly space-sensitive. In your Kubernetes .yaml files, never use the Tab key for indentation. Use the Spacebar (usually two spaces per level). A single misaligned space will cause Kubernetes to reject the file with a frustrating syntax error.

Conclusion

Understanding Terraform and EKS is like unlocking a superpower for cloud computing. By writing your infrastructure as code, you can build, destroy, and rebuild complex architectures reliably in minutes.

Now that you know how to read a resource block, what a provider does, and the difference between HCL and YAML, you are completely prepared to tackle the advanced networking, security, and storage topics in the rest of this blog series. Welcome to the world of Infrastructure as Code!