DevOps4UA

project: real production-style Terraform

Jenkins

Source: Dev.to | Dec 19, 2025 (UTC)

1. Real Production Problem (WHY this approach exists)

Situation in real companies

In production you never have one Terraform project for everything.

Instead:

  • Networking team → VPC, subnets, gateways
  • Security team → IAM, security groups
  • App team → EC2, ECS, ALB, databases

Each team:

  • Works independently
  • Deploys at different times
  • Has separate CI/CD pipelines
  • Must NOT break other teams’ infrastructure

Problem if everything is in one Terraform project

  • One mistake → destroys shared resources
  • Teams block each other
  • Huge state file → risky
  • No ownership boundaries

Solution used in production

Each team owns its own Terraform project + state
and reads shared resources via data sources or remote state.

2. Production Architecture (Simple but Real)

AWS Account (Production) │ ├── networking-terraform/ │ └── creates VPC │ ├── security-terraform/ │ └── creates Security Groups │ └── app-team-terraform/ └── creates EC2 (Ubuntu) using existing VPC + SG

Enter fullscreen mode

Exit fullscreen mode

We will focus on App Team.

3. App Team Goal (WHAT they do)

App team wants:

This is exact real-world behavior.

4. App Team Terraform – Production-Style Code

Folder

app-team-ec2/ ├── main.tf ├── variables.tf └── terraform.tfvars

Enter fullscreen mode

Exit fullscreen mode

5. main.tf (Ubuntu AMI – us-west-1)

terraform { required_version = ">= 1.5.0" } provider "aws" { region = "us-west-1" }

Enter fullscreen mode

Exit fullscreen mode

🔹 Fetch Latest Ubuntu AMI (Production best practice)

data "aws_ami" "ubuntu" { most_recent = true owners = ["099720109477"] # Canonical (official Ubuntu) filter { name = "name" values = ["ubuntu/images/hvm-ssd/ubuntu-jammy-22.04-amd64-server-*"] } filter { name = "virtualization-type" values = ["hvm"] } }

Enter fullscreen mode

Exit fullscreen mode

Why this is production-grade:

🔹 Read Existing VPC (owned by networking team)

data "aws_vpc" "prod" { tags = { Name = "prod-vpc" } }

Enter fullscreen mode

Exit fullscreen mode

App team does not create VPC
They only consume it.

🔹 Read Existing Security Group (owned by security team)

data "aws_security_group" "app_sg" { name = "prod-app-sg" vpc_id = data.aws_vpc.prod.id }

Enter fullscreen mode

Exit fullscreen mode

Security team controls:

🔹 Create EC2 (App Team responsibility)

resource "aws_instance" "app_server" { ami = data.aws_ami.ubuntu.id instance_type = var.instance_type subnet_id = var.subnet_id vpc_security_group_ids = [ data.aws_security_group.app_sg.id ] tags = { Name = "prod-app-server" Team = "app" Environment = "production" } }

Enter fullscreen mode

Exit fullscreen mode

6. variables.tf

variable "instance_type" { type = string default = "t3.micro" } variable "subnet_id" { type = string }

Enter fullscreen mode

Exit fullscreen mode

7. terraform.tfvars

subnet_id = "subnet-0abc123456789def"

Enter fullscreen mode

Exit fullscreen mode

Subnet comes from:

8. Commands App Team Runs (Real Production Flow)

terraform init terraform validate terraform plan terraform apply

Enter fullscreen mode

Exit fullscreen mode

No dependency on other teams’ pipelines.

9. Why This Is REAL Production Design

Separation of ownership

Team

Owns

Networking

VPC, Subnets

Security

Security Groups

App Team

EC2, ECS, ALB

Safety

Scalability

10. Interview-Ready Explanation (Use This)

In production, each team owns its own Terraform project and state.
Shared infrastructure like VPC and security groups are created by core teams and consumed using data sources or remote state.
This prevents accidental deletion, enables parallel deployments, and enforces clear ownership boundaries.

11. Why Ubuntu AMI via Data Source Is Mandatory in Prod

❌ Hard-coded AMI
✔️ Dynamic AMI lookup

Benefits:

12. What This Demonstrates

For further actions, you may consider blocking this person and/or reporting abuse

Залишити відповідь

Ваша e-mail адреса не оприлюднюватиметься. Обов’язкові поля позначені *

Читайте також