AWS Infrastructure Automation with Terraform

Project Overview

I built and validated the AWS infrastructure foundation for a multi-service Cloud & DevOps platform using Terraform. The environment supported Amazon EKS, private Amazon ECR repositories, Kubernetes workloads, persistent storage, GitOps delivery and the observability stack used across the rest of this portfolio.

The infrastructure was treated as a complete lifecycle exercise rather than a collection of console-created resources: provision through code, validate the running platform, capture implementation evidence, troubleshoot integrations, and safely decommission the environment when continuous AWS runtime was no longer required.

Engineering Problem

The platform needed a repeatable AWS foundation that could support containerized applications and Kubernetes operations without relying on manual cloud configuration. The infrastructure also needed to remain independently maintainable from application source and Kubernetes desired state.

• Avoid manual AWS provisioning and configuration drift.
• Provide a managed Kubernetes foundation for development, staging and production-style workloads.
• Maintain private and independently versioned container image repositories.
• Support persistent Kubernetes storage through AWS-native integration.
• Keep infrastructure, application source and GitOps desired state separated.
• Protect credentials, Terraform state and application secrets from public source control.
• Keep the portfolio reproducible without paying indefinitely for idle cloud infrastructure.

Solution Architecture

Terraform provisions the AWS infrastructure layer. Amazon EKS provides the managed Kubernetes control plane, EC2 worker nodes supplied workload capacity during validation, and Amazon ECR stored the application images consumed by Kubernetes. AWS networking, load-balancing, identity and storage integrations supported ingress and persistent workloads while the infrastructure, application and GitOps repositories remained separate.

Git / Infrastructure Repository
            ↓
         Terraform
            ↓
     AWS Infrastructure
   ├── Network foundation
   ├── Amazon EKS cluster
   ├── Worker-node capacity
   ├── Amazon ECR repositories
   ├── IAM / Pod Identity integration
   └── EBS CSI storage support
            ↓
      Kubernetes Platform
            ↓
 Applications + Observability

What I Built

• Terraform-managed AWS network and platform infrastructure.
• Amazon EKS cluster portfolio-dev.
• Managed EC2 worker capacity for Kubernetes workloads.
• Four private Amazon ECR repositories for frontend, API, authentication and worker services.
• Immutable ECR image tags and scan-on-push configuration.
• EBS CSI integration for Kubernetes persistent storage.
• EKS Pod Identity integration supporting AWS storage access.
• Infrastructure boundaries separate from application and GitOps repositories.

During platform validation, the EKS environment ran Kubernetes 1.36 with four t3.medium worker nodes. Kubernetes access was configured successfully and the nodes were verified Ready.

portfolio-dev/platform-frontend
portfolio-dev/platform-api
portfolio-dev/platform-auth
portfolio-dev/platform-worker

Terraform Workflow

The development configuration is maintained under terraform/environments/dev. Infrastructure changes were validated before application and followed with runtime verification after provisioning.

terraform init
terraform fmt -check
terraform validate
terraform plan
terraform apply

The initial successful plan contained 26 resources to add. The important engineering outcome was not the resource count itself, but that proposed infrastructure changes were visible before execution and could be reviewed as version-controlled code.

Terraform source change
        ↓
format / validate
        ↓
terraform plan
        ↓
review proposed changes
        ↓
terraform apply
        ↓
AWS infrastructure
        ↓
AWS CLI / kubectl verification

Challenges & How I Solved Them

Persistent Storage Required AWS Integration

The observability platform later required Grafana state to survive pod recreation. Kubernetes configuration alone was not enough because the cluster needed an AWS storage integration capable of provisioning and attaching EBS-backed volumes.

I added EBS CSI support through Terraform and integrated it with EKS Pod Identity. I then verified the integration against the running Kubernetes platform before using the storage for the observability workload. This kept the cloud dependency reproducible instead of relying on an undocumented manual cluster change.

Release Images Needed Traceable Identities

Using mutable image references would make it difficult to prove which CI build was running in each environment. I configured separate private ECR repositories and immutable release tags so a container image could be traced from CI to ECR, GitOps configuration and the running Kubernetes workload.

Infrastructure and Deployment State Needed Clear Ownership

Combining Terraform, application source and Kubernetes desired state in one repository would tightly couple unrelated lifecycle concerns. I separated the infrastructure repository from the application and GitOps repositories so AWS provisioning, software delivery and Kubernetes reconciliation can evolve independently.

Security & State Handling

• AWS credentials are handled outside Terraform source rather than embedded in configuration files.
• Application secrets are not committed to the public GitOps repository.
• Private Amazon ECR repositories were used for application images.
• Immutable image tags improve release traceability.
• Scan-on-push was enabled for the container repositories.
• Infrastructure source remains separate from application and Kubernetes desired state.
• Terraform state and sensitive runtime values are kept out of public source control.

Cost & Lifecycle Management

I treated infrastructure teardown as part of the engineering lifecycle rather than leaving portfolio resources running after validation. Before decommissioning the environment, source code, infrastructure evidence and PostgreSQL recovery artifacts were preserved. The AWS runtime was then removed so the environment could stop accumulating unnecessary compute, Kubernetes control-plane, networking and storage charges.

This creates a practical portfolio operating model:

Build
  ↓
Validate
  ↓
Capture Evidence
  ↓
Document
  ↓
Destroy Runtime
  ↓
Recreate from Code When Needed

The website and Git repositories remain available independently of the temporary AWS runtime.

Verified Evidence

• Terraform was successfully initialized, formatted, validated, planned and applied against AWS.
• The initial successful infrastructure plan contained 26 resources to add.
• The portfolio-dev Amazon EKS cluster was provisioned and accessed successfully.
• During validation, Kubernetes 1.36 ran on four t3.medium workers and the nodes were verified Ready.
• Four private ECR repositories were created for the frontend, API, authentication and worker services.
• ECR repositories used immutable tags and scan-on-push.
• Application images were pushed to ECR and consumed by Kubernetes workloads.
• EBS CSI support was integrated through Terraform and EKS Pod Identity and verified for persistent Kubernetes storage.
• The AWS foundation supported the Kubernetes, CI/CD, GitOps and observability projects documented elsewhere in this portfolio.
• After evidence capture, the environment was safely decommissioned and the final portfolio cost-driver audit returned no remaining known runtime resources in the portfolio region.

Production Considerations

The portfolio environment was designed as a hands-on engineering platform rather than a permanent enterprise production estate. For a larger production implementation I would extend the lifecycle with:

• A protected remote Terraform state backend with locking and tightly controlled access.
• Automated CI policy gates for formatting, validation, security scanning and plan review.
• Environment-specific approval controls for infrastructure changes.
• Formal backup, disaster-recovery and retention policies for persistent data.
• Budget alerts, tagging standards and automated cost-governance controls.
• Expanded policy-as-code and automated compliance checks.

Source Code & Evidence

The Terraform source and environment configuration are maintained in the infrastructure repository below. Runtime evidence was captured during the build and validation stages before the temporary AWS environment was decommissioned.

View Infrastructure Repository →

Engineering Value

This project demonstrates more than Terraform syntax. I designed the AWS foundation, provisioned it as code, validated the running infrastructure, integrated Kubernetes storage and identity requirements, connected the platform to CI/CD and GitOps workflows, preserved operational evidence and safely decommissioned the environment when continuous runtime was no longer justified.

It reflects the way I approach Cloud & DevOps engineering: build repeatable systems, verify them after deployment, troubleshoot integration problems across infrastructure layers, protect sensitive state, document evidence and consider operational cost throughout the infrastructure lifecycle.