Forem: POTHURAJU JAYAKRISHNA YADAV

Terraform Modular EKS + Istio — Part 5

POTHURAJU JAYAKRISHNA YADAV — Fri, 27 Mar 2026 02:49:35 +0000

CSI Drivers (How Storage Actually Works in EKS)

So far:

VPC → network
IAM → permissions
EKS → control plane
Nodes → compute

Now comes the part many people ignore:

👉 Storage

Without this:

Pods can’t persist data
Databases won’t work
Logs disappear on restart

This module installs CSI drivers, which allow Kubernetes to use AWS storage.

📂 Module Files

modules/csi-driver/
├── main.tf
├── variables.tf
└── outputs.tf

📄 variables.tf

variable "cluster_name" {
  description = "Name of the EKS cluster"
  type        = string
}

variable "ebs_csi_role_arn" {
  description = "IAM role ARN for EBS CSI driver"
  type        = string
}

variable "s3_csi_role_arn" {
  description = "IAM role ARN for S3 CSI driver"
  type        = string
}

variable "node_group_dependency" {
  description = "Node group dependency to ensure nodes exist first"
  type        = any
}

🧠 What these inputs mean

cluster_name → where to install addons
ebs_csi_role_arn → IAM role for EBS driver
s3_csi_role_arn → IAM role for S3 driver
node_group_dependency → ensures nodes exist first

⚠️ Important insight

This module depends on:

👉 IAM (for IRSA roles)
👉 Node groups (for scheduling pods)

📄 main.tf

1. EBS CSI Driver

resource "aws_eks_addon" "ebs_csi" {
  cluster_name             = var.cluster_name
  addon_name               = "aws-ebs-csi-driver"
  service_account_role_arn = var.ebs_csi_role_arn

  depends_on = [var.node_group_dependency]
}

🧠 What this does

Installs:

👉 AWS EBS CSI Driver inside cluster

What is CSI?

CSI = Container Storage Interface

👉 It allows Kubernetes to talk to AWS storage.

What EBS CSI enables

Create EBS volumes
Attach volumes to pods
Persist data

Important line

service_account_role_arn = var.ebs_csi_role_arn

👉 This is IRSA

This means:

Pod gets IAM role
Pod can call AWS APIs

Without this

❌ Pod cannot create volumes
❌ PVC fails

2. S3 CSI Driver

resource "aws_eks_addon" "s3_csi" {
  cluster_name             = var.cluster_name
  addon_name               = "aws-mountpoint-s3-csi-driver"
  service_account_role_arn = var.s3_csi_role_arn

  depends_on = [var.node_group_dependency]
}

🧠 What this does

Installs:

👉 S3 CSI driver

What it enables

Mount S3 bucket as:

Pod → S3 bucket (like filesystem)

Use cases

logs
shared storage
backups

3. Dependency Handling

depends_on = [var.node_group_dependency]

Why this is critical

CSI driver runs as pods.

👉 Pods need nodes

So order must be:

Nodes → CSI Driver

Without this

Addon installs
But pods fail to schedule

📄 outputs.tf

output "ebs_csi_addon_id" {
  description = "EBS CSI addon ID"
  value       = aws_eks_addon.ebs_csi.id
}

output "s3_csi_addon_id" {
  description = "S3 CSI addon ID"
  value       = aws_eks_addon.s3_csi.id
}

🧠 Why outputs matter

Used for:

tracking addon deployment
debugging
dependencies in future modules

🔥 What You Actually Built

Kubernetes Pod
      │
      │
CSI Driver
      │
      │
AWS Storage (EBS / S3)

⚠️ Real Issues People Face

Missing IRSA → access denied
No node dependency → pods fail
Wrong role → volume attach fails
Forgetting CSI → PVC stuck in pending

🧠 Key Takeaways

Kubernetes doesn’t manage storage directly
CSI drivers connect Kubernetes to AWS
IRSA is required for secure access
EBS = block storage
S3 = object storage

🚀 Next

In Part 6:

👉 AWS Load Balancer Controller
👉 How ALB actually integrates with Kubernetes
👉 Why target-type: ip matters

At this point, your cluster can:

run workloads
persist data

Now we move to traffic layer.

Terraform Modular EKS + Istio — Part 4

POTHURAJU JAYAKRISHNA YADAV — Fri, 27 Mar 2026 02:47:10 +0000

EKS Node Groups (Where Your Cluster Actually Gets Compute)

In the previous part, we created the EKS control plane.

At that point:

Kubernetes API exists
Cluster is reachable

But:

👉 There are no machines to run workloads

That’s where Node Groups come in.

This module creates the actual EC2 instances that:

join the cluster
run pods
execute your applications

📂 Module Files

modules/eks-nodes/
├── main.tf
├── variables.tf
└── outputs.tf

📄 variables.tf

variable "cluster_name" {
  description = "Name of the EKS cluster"
  type        = string
}

variable "node_group_name" {
  description = "Name of the EKS node group"
  type        = string
}

variable "node_role_arn" {
  description = "ARN of the EKS node group IAM role"
  type        = string
}

variable "subnet_ids" {
  description = "List of subnet IDs"
  type        = list(string)
}

variable "instance_types" {
  description = "List of instance types"
  type        = list(string)
  default     = ["t3.large"]
}

variable "desired_size" {
  description = "Desired number of nodes"
  type        = number
  default     = 1
}

variable "max_size" {
  description = "Maximum number of nodes"
  type        = number
  default     = 2
}

variable "min_size" {
  description = "Minimum number of nodes"
  type        = number
  default     = 1
}

variable "max_unavailable" {
  description = "Maximum number of nodes unavailable during update"
  type        = number
  default     = 1
}

variable "labels" {
  description = "Key-value map of Kubernetes labels"
  type        = map(string)
  default     = {}
}

🧠 What these variables control

This module is completely configurable:

cluster → which EKS cluster to join
instance_types → what machines to use
scaling → how many nodes
labels → Kubernetes scheduling

Example thinking

dev → small nodes (t3.medium)
prod → bigger nodes (m5.large)

👉 Same code, different behavior.

📄 main.tf

1. Node Group Resource

resource "aws_eks_node_group" "nodes" {
  cluster_name    = var.cluster_name
  node_group_name = var.node_group_name
  node_role_arn   = var.node_role_arn
  subnet_ids      = var.subnet_ids

What this does

Creates:

👉 EC2 instances managed by EKS

These instances:

automatically join the cluster
register as Kubernetes nodes

Important inputs

cluster_name → which cluster to join
node_role_arn → permissions for nodes
subnet_ids → where nodes are created

Subnet choice

You are passing:

👉 private subnets

This means:

nodes do NOT have public IP
more secure
traffic goes through NAT

2. Instance Types

instance_types = var.instance_types

What this controls

Defines:

CPU
Memory
cost

Example:

t3.large → 2 vCPU, 8GB RAM

3. Scaling Configuration

scaling_config {
  desired_size = var.desired_size
  max_size     = var.max_size
  min_size     = var.min_size
}

Meaning

desired_size → current running nodes
min_size → minimum nodes
max_size → maximum nodes

Example

min = 1
desired = 2
max = 5

👉 Cluster can scale between 1–5 nodes

4. Update Configuration

update_config {
  max_unavailable = var.max_unavailable
}

Why this matters

Controls rolling updates.

Example:

max_unavailable = 1

👉 Only 1 node can be down during update

Why important

prevents downtime
controls deployment safety

5. Labels

labels = var.labels

What labels do

Labels are used by Kubernetes for:

scheduling
targeting workloads

Example:

env = dev
type = backend

👉 Later you can do:

nodeSelector:
  type: backend

6. Dependency

depends_on = [var.node_role_arn]

Why this is needed

Even though role is passed:

Terraform might not always guarantee order.

So this ensures:

👉 IAM role exists before node creation

📄 outputs.tf

output "node_group_arn" {
  description = "Amazon Resource Name (ARN) of the EKS Node Group"
  value       = aws_eks_node_group.nodes.arn
}

output "node_group_status" {
  description = "Status of the EKS Node Group"
  value       = aws_eks_node_group.nodes.status
}

🧠 Why outputs matter

These outputs help in:

debugging
monitoring
integration with other modules

🔥 What You Actually Built

EKS Control Plane
        │
        │
Managed Node Group (EC2 Instances)
        │
        │
Kubernetes Pods run here

⚠️ Real Issues People Face

Wrong subnet → nodes can’t join
Missing IAM role → node creation fails
No NAT → nodes can’t pull images
Too small instance → pods crash

🧠 Key Takeaways

Node group = actual compute layer
Control plane alone is useless without nodes
Scaling config controls capacity
Labels help in workload placement

🚀 Next

In Part 5:

👉 Addons + CSI Driver
👉 How storage works in EKS
👉 Why IRSA becomes critical

At this point, your cluster is alive — now we make it usable.

Terraform Modular EKS + Istio — Part 3

POTHURAJU JAYAKRISHNA YADAV — Fri, 27 Mar 2026 02:45:23 +0000

EKS Cluster Module (What Actually Creates Kubernetes)

After setting up VPC and IAM, the next step is creating the actual Kubernetes control plane using Amazon EKS.

This module is responsible for:

Creating the EKS cluster
Configuring networking
Enabling authentication
Setting up OIDC (required for IRSA)

📂 Module Files

modules/eks-cluster/
├── main.tf
├── variables.tf
└── outputs.tf

📄 variables.tf

variable "cluster_name" {
  description = "Name of the EKS cluster"
  type        = string
}

variable "cluster_version" {
  description = "Kubernetes version"
  type        = string
  default     = "1.29"
}

variable "cluster_role_arn" {
  description = "ARN of the EKS cluster IAM role"
  type        = string
}

variable "private_subnet_ids" {
  description = "List of private subnet IDs"
  type        = list(string)
}

variable "public_subnet_ids" {
  description = "List of public subnet IDs"
  type        = list(string)
}

🧠 What this module expects

This module doesn’t create everything itself. It depends on:

VPC module → for subnets
IAM module → for cluster role

Inputs tell it:

what to name the cluster
which version to run
where to place it

📄 main.tf

This is where the actual EKS cluster is created.

1. EKS Cluster Resource

resource "aws_eks_cluster" "cluster" {
  name     = var.cluster_name
  version  = var.cluster_version
  role_arn = var.cluster_role_arn

What this does

This creates the EKS control plane.

Important point:

👉 You are NOT creating master nodes
👉 AWS manages them for you

2. Networking Configuration

vpc_config {
  subnet_ids = concat(var.private_subnet_ids, var.public_subnet_ids)
}

Why both private and public subnets?

Private subnets → worker nodes
Public subnets → load balancers

If you only pass private:

ALB/NLB creation can fail later

If you only pass public:

not secure

👉 Passing both is correct production setup.

3. Access Configuration (Very Important)

access_config {
  authentication_mode                         = "API_AND_CONFIG_MAP"
  bootstrap_cluster_creator_admin_permissions = true
}

What this solves

Newer EKS versions changed authentication behavior.

This block ensures:

API-based authentication is enabled
IAM + aws-auth both work

This line is critical

bootstrap_cluster_creator_admin_permissions = true

👉 Gives admin access to the creator

Without this:

cluster gets created
but you cannot access it

4. Dependency Handling

depends_on = [var.cluster_role_arn]

Why needed?

Even though role ARN is passed:

Terraform may not always detect dependency properly.

This ensures:

👉 IAM role exists before cluster creation

🔥 OIDC Setup (Core Concept)

This is the most important part of this module.

5. Fetch TLS Certificate

data "tls_certificate" "cluster" {
  url = aws_eks_cluster.cluster.identity[0].oidc[0].issuer
}

What is happening?

EKS creates an OIDC endpoint
This block fetches its certificate

Used for:
👉 Trust verification in IAM

6. Create OIDC Provider

resource "aws_iam_openid_connect_provider" "cluster" {
  client_id_list  = ["sts.amazonaws.com"]
  thumbprint_list = [data.tls_certificate.cluster.certificates[0].sha1_fingerprint]
  url             = aws_eks_cluster.cluster.identity[0].oidc[0].issuer

What this actually does

This creates a bridge:

Kubernetes → IAM

Why this is required

Without OIDC:

❌ Pods cannot assume IAM roles
❌ IRSA will not work

Thumbprint

thumbprint_list = [...]

👉 Ensures secure trust between AWS and OIDC provider

📄 outputs.tf

output "cluster_id" {
  value = aws_eks_cluster.cluster.id
}

output "cluster_arn" {
  value = aws_eks_cluster.cluster.arn
}

output "cluster_endpoint" {
  value = aws_eks_cluster.cluster.endpoint
}

output "cluster_security_group_id" {
  value = aws_eks_cluster.cluster.vpc_config[0].cluster_security_group_id
}

output "cluster_certificate_authority_data" {
  value = aws_eks_cluster.cluster.certificate_authority[0].data
}

output "oidc_provider_arn" {
  value = aws_iam_openid_connect_provider.cluster.arn
}

output "oidc_provider" {
  value = replace(aws_eks_cluster.cluster.identity[0].oidc[0].issuer, "https://", "")
}

🧠 Why these outputs matter

These values are used by other modules:

Kubernetes provider → uses endpoint + certificate
IAM module → uses OIDC provider
Node module → uses cluster name

Example:

host = module.eks_cluster.cluster_endpoint

🔥 What You Actually Built

AWS Managed Control Plane
        │
        │
OIDC Provider (for IAM integration)

⚠️ Real Issues People Face

No OIDC → IRSA breaks
Wrong subnets → cluster unstable
Missing access_config → login issues
Wrong IAM role → cluster creation fails

🧠 Key Takeaways

EKS cluster = control plane only
AWS manages master nodes
OIDC is required for IAM integration
Outputs connect modules together

🚀 Next Step

Next module:

👉 Node Groups (actual compute layer)
👉 How EC2 instances join the cluster
👉 Scaling and updates

This module is where Kubernetes actually starts — but without nodes, it’s still empty.

Terraform Modular EKS + Istio — Part 2

POTHURAJU JAYAKRISHNA YADAV — Fri, 27 Mar 2026 02:40:48 +0000

IAM Module (IRSA, OIDC, and Why This Controls Everything)

In the previous part, we built the VPC.

Now we move to something that causes the most confusion in EKS setups:

👉 IAM

This is not just “permissions”.

This module controls:

how EKS works
how nodes behave
how pods access AWS services

If this is wrong:

ALB won’t work
CSI drivers fail
Pods can’t access AWS
Debugging becomes painful

📂 Module Files

modules/iam/
├── main.tf
├── variables.tf
└── outputs.tf

📄 variables.tf

variable "cluster_name" {
  description = "Name of the EKS cluster"
  type        = string
}

variable "oidc_provider_arn" {
  description = "ARN of the OIDC provider"
  type        = string
}

variable "oidc_provider" {
  description = "OIDC provider URL"
  type        = string
}

🧠 What these inputs mean

cluster_name
→ used to name roles
oidc_provider_arn
→ comes from EKS module
oidc_provider
→ used for IRSA condition matching

👉 Important:

This module depends on EKS
Because OIDC is created inside the EKS module.

📄 main.tf (Core IAM Logic)

1. EKS Cluster Role

resource "aws_iam_role" "eks_cluster" {
  name = "${var.cluster_name}-cluster-role"

  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Action = "sts:AssumeRole"
        Effect = "Allow"
        Principal = {
          Service = "eks.amazonaws.com"
        }
      }
    ]
  })
}

🧠 What this actually does

This role is used by:

👉 EKS Control Plane (managed by AWS)

Key line

Service = "eks.amazonaws.com"

👉 Means:

“EKS service is allowed to assume this role”

Attach Policy

resource "aws_iam_role_policy_attachment" "eks_cluster_policy" {
  policy_arn = "arn:aws:iam::aws:policy/AmazonEKSClusterPolicy"
  role       = aws_iam_role.eks_cluster.name
}

Why this policy?

This allows EKS to:

manage nodes
communicate with AWS
create resources

2. Node Group Role

resource "aws_iam_role" "eks_nodes" {
  name = "${var.cluster_name}-node-group-role"

  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Action = "sts:AssumeRole"
        Effect = "Allow"
        Principal = {
          Service = "ec2.amazonaws.com"
        }
      }
    ]
  })
}

🧠 What this role is for

👉 Used by EC2 instances (worker nodes)

Key line

Service = "ec2.amazonaws.com"

👉 Means:

EC2 instances can assume this role

3. Node Policies

Now we attach multiple policies.

a. Worker Node Policy

resource "aws_iam_role_policy_attachment" "eks_worker_node_policy" {
  policy_arn = "arn:aws:iam::aws:policy/AmazonEKSWorkerNodePolicy"
}

👉 Allows nodes to:

join cluster
communicate with control plane

b. CNI Policy

resource "aws_iam_role_policy_attachment" "eks_cni_policy" {
  policy_arn = "arn:aws:iam::aws:policy/AmazonEKS_CNI_Policy"
}

👉 This is very important

Allows:

Pod networking
ENI management

👉 Without this:
Pods won’t get IPs

c. ECR Access

resource "aws_iam_role_policy_attachment" "eks_container_registry_policy" {
  policy_arn = "arn:aws:iam::aws:policy/AmazonEC2ContainerRegistryReadOnly"
}

👉 Allows nodes to:

pull Docker images

d. SSM Access

resource "aws_iam_role_policy_attachment" "eks_ssm_policy" {
  policy_arn = "arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore"
}

👉 Allows:

SSM access
no need for SSH

👉 This is production best practice

4. EBS CSI Driver Role (🔥 Most Important Part)

resource "aws_iam_role" "ebs_csi_driver" {
  name = "${var.cluster_name}-ebs-csi-driver-role"

This is NOT for nodes.

This is for:

👉 Kubernetes Pod (EBS CSI controller)

🔥 This is IRSA (Core Concept)

Action = "sts:AssumeRoleWithWebIdentity"

👉 This is different from EC2 roles

This allows:

👉 Pods → assume IAM role

🔥 OIDC Trust

Principal = {
  Federated = var.oidc_provider_arn
}

👉 This links:

EKS cluster
IAM

🔥 Condition (VERY IMPORTANT)

"${var.oidc_provider}:sub" = "system:serviceaccount:kube-system:ebs-csi-controller-sa"

👉 This means:

ONLY this service account can assume the role:

kube-system / ebs-csi-controller-sa

Why this matters

👉 This is fine-grained security

Instead of:

❌ giving full access to nodes

You do:

✅ give access only to specific pod

Attach Policy

resource "aws_iam_role_policy_attachment" "ebs_csi_policy" {
  policy_arn = "arn:aws:iam::aws:policy/service-role/AmazonEBSCSIDriverPolicy"
}

What this enables

Create volumes
Attach volumes
Manage storage

📄 outputs.tf

output "eks_cluster_role_arn" {
  value = aws_iam_role.eks_cluster.arn
}

output "eks_nodes_role_arn" {
  value = aws_iam_role.eks_nodes.arn
}

output "ebs_csi_driver_role_arn" {
  value = aws_iam_role.ebs_csi_driver.arn
}

🧠 Why outputs matter

These are used in:

EKS module
Node module
CSI module

Example:

cluster_role_arn = module.iam.eks_cluster_role_arn

👉 This creates dependency automatically.

🔥 Real Architecture (What You Built)

EKS Control Plane → uses cluster role

EC2 Nodes → use node role

Pods (CSI) → use IRSA role (OIDC)

⚠️ Real Mistakes People Make

Giving full IAM to nodes (bad security)
Not using IRSA
Wrong OIDC condition → role not assumed
Forgetting CNI policy → pods fail

🧠 Key Takeaways

IAM is not optional — it defines system behavior
Nodes and pods should have separate roles
IRSA is the correct way to give AWS access to pods
OIDC is what connects Kubernetes to IAM

🚀 Next

In Part 3:

👉 EKS Cluster Module
👉 How control plane is created
👉 What OIDC actually does internally

If you understand this module, you understand how AWS + Kubernetes actually connect behind the scenes.

Terraform Modular EKS + Istio — Part 1

POTHURAJU JAYAKRISHNA YADAV — Fri, 27 Mar 2026 02:37:41 +0000

VPC Module (Complete Code + Real Explanation)

Before touching EKS, Istio, or routing — everything depends on one thing:

👉 Your network

If the VPC is wrong:

Nodes won’t join
ALB won’t work
Pods won’t get IPs
Routing will fail in weird ways

So in this part, I’ll walk through the entire VPC module from my setup, using the exact code — and explain what each part is doing and why it exists.

📂 Module Files

This module consists of 3 files:

modules/vpc/
├── main.tf
├── variables.tf
└── outputs.tf

📄 variables.tf

This file defines what inputs the module expects.

variable "vpc_name" {
  description = "Name of the VPC"
  type        = string
}

variable "vpc_cidr" {
  description = "CIDR block for VPC"
  type        = string
  default     = "10.0.0.0/16"
}

variable "availability_zones" {
  description = "Availability zones"
  type        = list(string)
}

variable "private_subnet_cidrs" {
  description = "CIDR blocks for private subnets"
  type        = list(string)
}

variable "public_subnet_cidrs" {
  description = "CIDR blocks for public subnets"
  type        = list(string)
}

variable "cluster_name" {
  description = "Name of the EKS cluster"
  type        = string
}

🧠 What this means

This module is not hardcoded.

Everything is controlled from outside:

CIDR ranges
AZs
Subnet layout
Cluster name

👉 That’s what makes it reusable across:

dev
staging
prod

📄 main.tf (Core Logic)

This is where actual infrastructure is created.

1. VPC

resource "aws_vpc" "main" {
  cidr_block           = var.vpc_cidr
  enable_dns_support   = true
  enable_dns_hostnames = true

  tags = {
    Name = var.vpc_name
  }
}

Why this matters

cidr_block → defines network size
enable_dns_support → required for internal communication
enable_dns_hostnames → required for:
- EKS
- ALB
- service discovery

👉 If DNS is off, things break silently.

2. Private Subnets (EKS Nodes)

resource "aws_subnet" "private_subnets" {
  count             = length(var.private_subnet_cidrs)
  vpc_id            = aws_vpc.main.id
  cidr_block        = var.private_subnet_cidrs[count.index]
  availability_zone = var.availability_zones[count.index]

What’s happening

count creates multiple subnets
Each subnet is tied to an AZ

🔥 Important Tags

tags = {
  Name                              = "${var.vpc_name}-private-${var.availability_zones[count.index]}"
  "kubernetes.io/role/internal-elb" = "1"
  "kubernetes.io/cluster/${var.cluster_name}" = "owned"
}

Why these tags matter

These are not optional

internal-elb
→ used by AWS to place internal load balancers
cluster tag
→ required for EKS to discover subnets

👉 Missing this = ALB or services fail later

3. Public Subnets (ALB Layer)

resource "aws_subnet" "public_subnets" {
  count                   = length(var.public_subnet_cidrs)
  vpc_id                  = aws_vpc.main.id
  cidr_block              = var.public_subnet_cidrs[count.index]
  availability_zone       = var.availability_zones[count.index]
  map_public_ip_on_launch = true

Key difference

map_public_ip_on_launch = true

👉 Instances here get public IPs

Tag Difference

"kubernetes.io/role/elb" = "1"

👉 This tells AWS:

“Use this subnet for internet-facing load balancers”

4. Internet Gateway

resource "aws_internet_gateway" "igw" {
  vpc_id = aws_vpc.main.id

  tags = {
    Name = "${var.vpc_name}-igw"
  }
}

Purpose

Allows:

👉 Public subnet → Internet

5. Elastic IP (for NAT)

resource "aws_eip" "nat" {
  count  = length(var.public_subnet_cidrs)
  domain = "vpc"

  tags = {
    Name = "${var.vpc_name}-nat-${count.index + 1}"
  }

  depends_on = [aws_internet_gateway.igw]
}

Why EIP?

NAT Gateway needs a public IP

6. NAT Gateway (Critical)

resource "aws_nat_gateway" "nat" {
  count         = length(var.public_subnet_cidrs)
  allocation_id = aws_eip.nat[count.index].id
  subnet_id     = aws_subnet.public_subnets[count.index].id

What it does

Private Subnet → NAT → Internet

👉 Nodes can:

pull Docker images
access APIs

BUT:

👉 They don’t get public IP (secure)

7. Private Route Table

resource "aws_route_table" "private" {
  count  = length(var.private_subnet_cidrs)
  vpc_id = aws_vpc.main.id

  route {
    cidr_block     = "0.0.0.0/0"
    nat_gateway_id = aws_nat_gateway.nat[count.index].id
  }
}

Meaning

All outbound traffic → NAT

8. Public Route Table

resource "aws_route_table" "public" {
  vpc_id = aws_vpc.main.id

  route {
    cidr_block = "0.0.0.0/0"
    gateway_id = aws_internet_gateway.igw.id
  }
}

Meaning

Public subnet → direct internet

9. Route Table Associations

resource "aws_route_table_association" "private" {
  count          = length(var.private_subnet_cidrs)
  subnet_id      = aws_subnet.private_subnets[count.index].id
  route_table_id = aws_route_table.private[count.index].id
}

resource "aws_route_table_association" "public" {
  count          = length(var.public_subnet_cidrs)
  subnet_id      = aws_subnet.public_subnets[count.index].id
  route_table_id = aws_route_table.public.id
}

Why needed

👉 Subnets don’t automatically get routing

You must attach:

subnet → route table

📄 outputs.tf

This file exposes values for other modules.

output "vpc_id" {
  description = "ID of the VPC"
  value       = aws_vpc.main.id
}

output "private_subnet_ids" {
  description = "IDs of the private subnets"
  value       = aws_subnet.private_subnets[*].id
}

output "public_subnet_ids" {
  description = "IDs of the public subnets"
  value       = aws_subnet.public_subnets[*].id
}

Why outputs matter

These are used by:

EKS cluster
Node groups
ALB controller

Example:

private_subnet_ids = module.vpc.private_subnet_ids

👉 This creates dependency automatically.

🧠 Final Architecture

Internet
   │
Internet Gateway
   │
Public Subnets (ALB)
   │
NAT Gateway
   │
Private Subnets (EKS Nodes)

⚠️ Real Things That Break in Production

Missing subnet tags → ALB won’t create
No NAT → nodes can’t pull images
Wrong AZ mapping → cluster unstable
Public nodes → security issue

🧠 Key Takeaways

VPC is the foundation of everything
Subnet tagging is critical for EKS
NAT enables private nodes
Outputs drive Terraform dependencies

🚀 Next

In Part 2:

👉 IAM Module — IRSA explained properly
👉 How pods assume AWS roles
👉 Why OIDC is required

If you're building EKS in production, this part is not optional — this is where most issues actually start.

🔍 Terraform Modular EKS + Istio — The Part Nobody Explains

POTHURAJU JAYAKRISHNA YADAV — Thu, 26 Mar 2026 12:17:09 +0000

When I first modularized my Terraform for EKS, everything looked clean…

Until it didn’t work.

Modules were correct.
Code was clean.
Folder structure looked “perfect”.

But Terraform was behaving in ways I didn’t expect.

Resources were creating in weird order.
Dependencies felt invisible.
And debugging became painful.

That’s when I realized:

👉 Understanding Terraform syntax is easy
👉 Understanding how Terraform thinks is the real game

This blog is about that shift.

🧠 The Biggest Misconception

Initially, I thought Terraform runs like a script:

Step 1 → Step 2 → Step 3

But that assumption is completely wrong.

Terraform doesn’t execute line by line.

👉 It builds a dependency graph first, and only then decides what to create and in what order.

Once this clicked, everything started making sense.

🧩 My Project Structure (Real Setup)

Here’s how I organized everything:

modularized/
├── eks/                      # Root module (entry point)
│   ├── main.tf
│   ├── variables.tf
│   ├── providers.tf
│   └── backend.tf
├── modules/
│   ├── vpc/
│   ├── iam/
│   ├── eks-cluster/
│   ├── eks-nodes/
│   ├── aws-load-balancer-controller/
│   ├── istio-base/
│   ├── istiod/
│   ├── istio-gateway/
│   └── istio-manifests/
└── environments/
    ├── dev/
    │   ├── terraform.tfvars
    │   └── backend.hcl

At a glance, this looks like just folders.

But in reality:

👉 This is a system design mapped into code

🔗 The Real Role of `main.tf`

Think of main.tf not as a file…

👉 But as an orchestrator

It doesn’t “do” things directly.
It connects modules together using data.

🔹 Step 1: VPC — The Foundation

module "vpc" {
  source               = "../modules/vpc"
  vpc_name             = var.vpc_name
  vpc_cidr             = var.vpc_cidr
  availability_zones   = var.availability_zones
  private_subnet_cidrs = var.private_subnet_cidrs
  public_subnet_cidrs  = var.public_subnet_cidrs
  cluster_name         = var.cluster_name
}

This module creates:

VPC
Public & private subnets
Routing

But the important part is not creation…

👉 It’s what it exports

output "private_subnet_ids" {
  value = aws_subnet.private[*].id
}

🧠 First Realization

Terraform modules don’t “talk” directly.

They communicate through:

👉 Outputs → Inputs

🔹 Step 2: IAM — Identity Layer

module "iam" {
  source       = "../modules/iam"
  cluster_name = var.cluster_name
}

This creates:

Cluster role
Node role
IRSA roles

And exposes:

output "eks_cluster_role_arn" {}
output "eks_nodes_role_arn" {}

🔗 Step 3: EKS Cluster — Where Things Clicked

module "eks_cluster" {
  source = "../modules/eks-cluster"

  cluster_name       = var.cluster_name
  cluster_version    = var.cluster_version
  cluster_role_arn   = module.iam.eks_cluster_role_arn
  private_subnet_ids = module.vpc.private_subnet_ids
  public_subnet_ids  = module.vpc.public_subnet_ids
}

This line changed everything for me:

module.iam.eks_cluster_role_arn

👉 This is not just a reference
👉 This is a dependency signal

💥 The Aha Moment

I didn’t define any order like:

“Create IAM first”
“Then VPC”
“Then EKS”

Yet Terraform automatically knew.

Why?

Because:

👉 Dependencies define execution order

🔹 Step 4: Node Groups — Implicit Dependency

module "eks_nodes" {
  source = "../modules/eks-nodes"

  cluster_name  = module.eks_cluster.cluster_id
  node_role_arn = module.iam.eks_nodes_role_arn
  subnet_ids    = module.vpc.private_subnet_ids
}

Now Terraform understands:

Nodes depend on cluster
Cluster depends on IAM + VPC

So it builds a graph like:

VPC → IAM → EKS → Nodes

Without you ever writing that flow.

⚠️ Mistake I Made (Important)

At one point, I hardcoded subnet IDs inside my EKS module.

It worked… initially.

But the moment I tried another environment — everything broke.

That’s when I understood:

👉 Hardcoding breaks modular design
👉 Outputs make modules reusable

⚙️ Variables — The Real Power

variable "cluster_name" {
  type = string
}

Values come from:

# environments/dev/terraform.tfvars

cluster_name = "dev-cluster"

👉 Same code
👉 Different environments

No duplication.

🧠 What Terraform Actually Does

When you run:

terraform apply

Terraform does NOT just “run code”.

It:

Reads variables
Resolves all references
Builds dependency graph
Plans execution order
Applies resources

🔐 Backend — Silent but Critical

terraform {
  backend "s3" {
    bucket = "my-tf-state"
    key    = "eks/dev/terraform.tfstate"
    region = "us-east-1"
  }
}

This enables:

Remote state
Team collaboration
State locking

Without this, things get messy fast.

🧠 Final Shift in Thinking

At the beginning, Terraform felt like:

👉 “Writing infrastructure scripts”

Now it feels like:

👉 “Designing systems using data flow”

That shift changes everything.

💡 Key Takeaways

main.tf is not execution — it’s orchestration
Outputs are how modules communicate
Dependencies are inferred, not written
Variables make environments scalable
Terraform is a graph engine, not a script runner

🔗 Repo

https://github.com/jayakrishnayadav24/istio-ip-based-routing

🚀 Final Thought

Once you stop thinking in terms of files…

And start thinking in terms of data flowing between modules…

Terraform stops being just infrastructure code.

👉 It becomes a system design tool.

If this helped you understand Terraform at a deeper level:

⭐ Star the repo
🔁 Share with others
💬 Let me know what confused you — I’ll write about it next

Happy building 🚀

🚀 Creating an EC2 Instance Using Python requests (Without boto3)

POTHURAJU JAYAKRISHNA YADAV — Tue, 24 Mar 2026 04:36:51 +0000

Most developers use boto3 to interact with AWS.

But have you ever wondered…

👉 What actually happens behind the scenes?
👉 How does AWS authenticate your API requests?

I always used boto3 without thinking much about it — until I tried calling AWS APIs directly.

In this blog, we’ll go one level deeper and:

🔥 Create an EC2 instance using raw HTTP requests with AWS Signature Version 4 (SigV4)

🧠 boto3 is Just a Wrapper

When you run:

ec2.run_instances(...)

Behind the scenes, boto3:

Builds an HTTP request
Signs it using AWS Signature Version 4
Sends it to AWS APIs

In this blog, we’ll do all of that manually.

⚙️ What We’re Building

We’ll create a Python script that:

Uses requests
Implements AWS SigV4 authentication
Launches a real EC2 instance

No SDK. No shortcuts.

🔄 High-Level Flow

Client → Canonical Request → String to Sign → Signature → AWS API → Response

🔐 Understanding AWS Signature Version 4 (SigV4)

AWS secures every API request using SigV4. It ensures:

Authentication (who you are)
Integrity (request not tampered)

💻 Full Working Code

import requests
import datetime
import hashlib
import hmac
import urllib.parse

# 🔐 AWS credentials
ACCESS_KEY = "YOUR_ACCESS_KEY"
SECRET_KEY = "YOUR_SECRET_KEY"

REGION = "ap-south-1"
SERVICE = "ec2"
HOST = f"ec2.{REGION}.amazonaws.com"
ENDPOINT = f"https://{HOST}/"

# 📦 EC2 parameters
params = {
    "Action": "RunInstances",
    "ImageId": "ami-0f5ee92e2d63afc18",
    "InstanceType": "t2.micro",
    "MinCount": "1",
    "MaxCount": "1",
    "Version": "2016-11-15"
}

# 🕒 Time
t = datetime.datetime.utcnow()
amz_date = t.strftime('%Y%m%dT%H%M%SZ')
date_stamp = t.strftime('%Y%m%d')

# 🔹 Step 1: Canonical Query String
canonical_querystring = '&'.join(
    f"{urllib.parse.quote(k)}={urllib.parse.quote(v)}"
    for k, v in sorted(params.items())
)

# 🔹 Step 2: Canonical Request
canonical_headers = f"host:{HOST}\nx-amz-date:{amz_date}\n"
signed_headers = "host;x-amz-date"
payload_hash = hashlib.sha256(b"").hexdigest()

canonical_request = (
    "GET\n"
    "/\n"
    f"{canonical_querystring}\n"
    f"{canonical_headers}\n"
    f"{signed_headers}\n"
    f"{payload_hash}"
)

# 🔹 Step 3: String to Sign
algorithm = "AWS4-HMAC-SHA256"
credential_scope = f"{date_stamp}/{REGION}/{SERVICE}/aws4_request"

string_to_sign = (
    f"{algorithm}\n"
    f"{amz_date}\n"
    f"{credential_scope}\n"
    f"{hashlib.sha256(canonical_request.encode()).hexdigest()}"
)

# 🔹 Step 4: Signing Key
def sign(key, msg):
    return hmac.new(key, msg.encode('utf-8'), hashlib.sha256).digest()

k_date = sign(("AWS4" + SECRET_KEY).encode(), date_stamp)
k_region = sign(k_date, REGION)
k_service = sign(k_region, SERVICE)
k_signing = sign(k_service, "aws4_request")

signature = hmac.new(
    k_signing,
    string_to_sign.encode(),
    hashlib.sha256
).hexdigest()

# 🔹 Step 5: Headers
authorization_header = (
    f"{algorithm} Credential={ACCESS_KEY}/{credential_scope}, "
    f"SignedHeaders={signed_headers}, Signature={signature}"
)

headers = {
    "x-amz-date": amz_date,
    "Authorization": authorization_header
}

# 🔹 Final request
request_url = ENDPOINT + "?" + canonical_querystring

print("👉 Calling:", request_url)

response = requests.get(request_url, headers=headers)

print("\nStatus Code:", response.status_code)
print("\nResponse:\n", response.text)

🔍 Breaking Down the Code (with Snippets)

Let’s understand what’s happening step by step.

🔐 1. AWS Credentials & Config

ACCESS_KEY = "YOUR_ACCESS_KEY"
SECRET_KEY = "YOUR_SECRET_KEY"

REGION = "ap-south-1"
SERVICE = "ec2"
HOST = f"ec2.{REGION}.amazonaws.com"

👉 Defines credentials + region + service endpoint.

📦 2. EC2 Parameters

params = {
    "Action": "RunInstances",
    "ImageId": "ami-0f5ee92e2d63afc18",
    "InstanceType": "t2.micro",
    "MinCount": "1",
    "MaxCount": "1",
    "Version": "2016-11-15"
}

👉 This is the actual API request payload.

🕒 3. Timestamp

t = datetime.datetime.utcnow()
amz_date = t.strftime('%Y%m%dT%H%M%SZ')

👉 Required for AWS request validation.

🔹 4. Canonical Query String

canonical_querystring = '&'.join(
    f"{urllib.parse.quote(k)}={urllib.parse.quote(v)}"
    for k, v in sorted(params.items())
)

👉 Sort + encode parameters
👉 Critical step (most common failure point)

🔹 5. Canonical Request

canonical_request = (
    "GET\n"
    "/\n"
    f"{canonical_querystring}\n"
    f"{canonical_headers}\n"
    f"{signed_headers}\n"
    f"{payload_hash}"
)

👉 Exact request AWS validates internally.

🔹 6. String to Sign

string_to_sign = (
    f"{algorithm}\n"
    f"{amz_date}\n"
    f"{credential_scope}\n"
    f"{hashlib.sha256(canonical_request.encode()).hexdigest()}"
)

👉 This is what gets signed.

🔑 7. Signing Key

k_date = sign(("AWS4" + SECRET_KEY).encode(), date_stamp)
k_region = sign(k_date, REGION)
k_service = sign(k_region, SERVICE)
k_signing = sign(k_service, "aws4_request")

👉 Multi-step key derivation:

Secret → Date → Region → Service → aws4_request

🔐 8. Signature

signature = hmac.new(
    k_signing,
    string_to_sign.encode(),
    hashlib.sha256
).hexdigest()

👉 Final cryptographic signature.

📬 9. Authorization Header

headers = {
    "x-amz-date": amz_date,
    "Authorization": authorization_header
}

👉 This header authenticates your request.

🌐 10. Sending Request

response = requests.get(request_url, headers=headers)

👉 Sends request → AWS validates → returns response.

🧠 Simple Analogy

Think of SigV4 like a sealed envelope:

Canonical request → message
Signing key → secret stamp
Signature → seal

AWS checks the seal before accepting it.

✅ Real Output

Status Code: 200
Instance created successfully
Instance ID: i-069a545b1814c6cec

⚠️ Common Errors

❌ SignatureDoesNotMatch

Wrong encoding
Params not sorted

I got SignatureDoesNotMatch for almost 30 minutes before realizing I wasn’t sorting parameters correctly.

❌ UnauthorizedOperation

Missing IAM permissions

❌ InvalidAMIID.NotFound

Wrong AMI

⚖️ boto3 vs requests

Feature	boto3	requests + SigV4
Ease	✅ Easy	❌ Complex
Control	❌ Limited	✅ Full
Use Case	Production	Learning

🧠 Key Takeaway

After doing this, boto3 didn’t feel like magic anymore — just automation over HTTP.

🚨 Important Note

Use this approach for:

✅ Learning
✅ Debugging
✅ Deep understanding

❌ Not production

✍️ Final Thought

The hardest part wasn’t writing the code — it was getting the signature exactly right.

🐳 Containerizing a Python FastAPI Application with Docker (and Solving ARM vs x86 Architecture Issues)

POTHURAJU JAYAKRISHNA YADAV — Sat, 07 Mar 2026 07:18:19 +0000

When working with containerized applications, Docker usually makes deployments predictable and consistent. Once everything is packaged inside a container, the expectation is simple: “If it works on my machine, it should work everywhere.”

However, real-world environments sometimes introduce subtle issues — especially when applications are built on machines with different CPU architectures, such as x86 (AMD64) and ARM64.

Recently, I was containerizing a small Python FastAPI application, and I noticed something interesting. The Docker image worked perfectly on my Ubuntu server but behaved differently on another machine. After some investigation, the root cause turned out to be architecture differences between systems.

In this article, I'll walk through the entire process:

Containerizing a FastAPI application with Docker
Running the application using Docker Compose
Understanding ARM vs x86 architecture differences
Troubleshooting Docker daemon issues
Building multi-architecture images

If you work with Python, FastAPI, Docker, or cloud deployments, this guide will help you avoid some common pitfalls.

📁 Project Structure

For this example, we'll use a simple API service called task-api-service.

The project structure looks like this:

task-api-service
│
├── Dockerfile
├── docker-compose.yml
├── requirements.txt
├── main.py
└── app/

The FastAPI application exposes a REST API running on port 8080.

🐍 Step 1 — Writing the Dockerfile

The first step is creating a Dockerfile to containerize the application.

We start with the official Python slim image, which provides a lightweight base environment.

FROM python:3.10-slim

ENV PYTHONDONTWRITEBYTECODE=1
ENV PYTHONUNBUFFERED=1

WORKDIR /app

RUN apt-get update && apt-get install -y \
    libgl1 \
    libglib2.0-0 \
    build-essential \
    && rm -rf /var/lib/apt/lists/*

COPY requirements.txt .

RUN pip install --upgrade pip \
    && pip install --no-cache-dir -r requirements.txt

COPY . .

EXPOSE 8080

CMD ["uvicorn","main:app","--host","0.0.0.0","--port","8080"]

Why these optimizations?

There are a few small improvements here that make the container more production-friendly.

1️⃣ Prevent Python cache files

PYTHONDONTWRITEBYTECODE=1

This prevents .pyc files from being created inside the container.

2️⃣ Better logging

PYTHONUNBUFFERED=1

This ensures logs are immediately visible in Docker logs.

3️⃣ Removing package cache

rm -rf /var/lib/apt/lists/*

This reduces the final image size.

🏗 Step 2 — Building the Docker Image

Once the Dockerfile is ready, we can build the image.

docker build -t task-api-service .

After building, verify the image:

docker images

You should see the new image listed.

🚀 Step 3 — Running the Container

Now we can run the container.

docker run -p 8088:8080 task-api-service

The application will now be accessible at:

http://localhost:8088

Docker maps:

Host Port 8088 → Container Port 8080

⚙️ Step 4 — Using Docker Compose

Managing containers manually becomes inconvenient as applications grow.

This is where Docker Compose becomes useful.

Create a file called docker-compose.yml.

version: "3.9"

services:
  fastapi-app:
    container_name: fastapi-app
    build:
      context: .
      dockerfile: Dockerfile
    ports:
      - "8088:8080"
    volumes:
      - .:/app
    restart: unless-stopped

📂 Why Use Volumes?

volumes:
  - .:/app

This mounts the local project directory into the container.

Benefits include:

Instant reflection of code changes
Faster development workflow
No need to rebuild images repeatedly

If you run Uvicorn with the --reload flag, the server automatically restarts when files change.

▶️ Running with Docker Compose

Start the application:

docker compose up --build

Run it in the background:

docker compose up -d

Stop the containers:

docker compose down

⚠️ The Architecture Problem (ARM vs x86)

Everything worked perfectly on my Ubuntu machine.

To check the system architecture, I ran:

uname -m

Output:

x86_64

This means the system uses AMD64 architecture.

However, many modern systems now use ARM architecture, including:

Apple Silicon Macs
AWS Graviton instances
Raspberry Pi servers

Running the same command on those systems usually returns:

arm64

This difference can cause compatibility issues when Docker images are built on one architecture and run on another.

🔧 Forcing a Specific Docker Platform

Docker allows specifying the target architecture during builds.

For example:

docker build --platform linux/arm64 -t task-api-service .

This forces Docker to build an ARM-compatible image.

You can also define the platform inside Docker Compose.

services:
  fastapi-app:
    build:
      context: .
    platform: linux/arm64
    ports:
      - "8088:8080"

🛠 Troubleshooting Docker Daemon Issues

During testing, I encountered an error like this:

Cannot connect to the Docker daemon at unix:///var/run/docker.sock

This usually means the Docker daemon is not running.

To verify Docker status:

sudo systemctl status docker

If the service is inactive, restart it:

sudo systemctl restart docker

Then confirm Docker is working:

docker ps

🔐 Fixing Docker Permission Issues

Another common issue occurs when Docker commands require sudo.

This happens because the user is not part of the Docker group.

To fix it:

sudo usermod -aG docker $USER

Then reload the shell:

newgrp docker

Now Docker commands can run without sudo.

🌍 Best Practice: Multi-Architecture Docker Images

Instead of building separate images for ARM and x86 systems, Docker allows multi-architecture builds.

Using Docker Buildx:

docker buildx build \
--platform linux/amd64,linux/arm64 \
-t myrepo/task-api-service:latest \
--push .

This creates a single image compatible with multiple architectures.

Official Docker images such as:

Python
Node.js
Nginx

all use this approach.

🧠 Final Thoughts

Docker makes it easy to package and deploy applications consistently, but architecture differences can sometimes introduce unexpected issues.

A few key lessons from this experience:

Always check system architecture using uname -m
Use Docker Compose for easier container management
Ensure the Docker daemon is running before troubleshooting builds
Consider multi-architecture images for production deployments

By understanding these concepts, you can ensure your containerized applications run smoothly across different environments, cloud platforms, and development machines.

🚀 Real-Time Data Replication Using MySQL, Debezium, Kafka, and Docker (CDC Guide)

POTHURAJU JAYAKRISHNA YADAV — Fri, 20 Feb 2026 03:11:12 +0000

📌 Introduction

Modern applications often need data to move between systems in real time — analytics platforms, microservices, search indexes, or backup databases.

Traditional approaches like batch jobs or cron-based sync introduce delays, inconsistencies, and operational complexity.

This is where Change Data Capture (CDC) becomes powerful.

In this article, we’ll build a simple but powerful real-time database replication pipeline using:

MySQL
Debezium
Apache Kafka
Kafka Connect (JDBC Sink)
Docker Compose

By the end, you’ll have a working system that automatically replicates inserts, updates, and deletes from one database to another.

🔥 What is Change Data Capture (CDC)?

Change Data Capture is a technique used to capture database changes (INSERT, UPDATE, DELETE) and stream them to other systems in real time.

Instead of polling the database repeatedly, CDC reads the database transaction log (binlog in MySQL).

This makes CDC:

✅ Real-time
✅ Efficient
✅ Reliable
✅ Scalable

❓ Why Do We Need CDC?

Common use cases:

Real-time analytics pipelines
Microservices data synchronization
Data warehousing
Cache invalidation
Event-driven architectures
Search indexing (Elasticsearch)
Zero-downtime migrations

Without CDC:

App → DB → Batch Job → Other Systems

With CDC:

App → DB → CDC Stream → Multiple Systems

Much faster and cleaner.

🏗 Architecture Overview

We will build the following pipeline:

MySQL Source
     ↓ (binlog)
Debezium Connector
     ↓
Kafka Topic
     ↓
JDBC Sink Connector
     ↓
MySQL Target

🐳 Step 1 — Docker Compose Setup

We’ll run everything using Docker so the setup is easy and reproducible.

Create a file called docker-compose.yml

services:

  zookeeper:
    image: confluentinc/cp-zookeeper:7.5.0
    environment:
      ZOOKEEPER_CLIENT_PORT: 2181

  kafka:
    image: confluentinc/cp-kafka:7.5.0
    depends_on:
      - zookeeper
    ports:
      - "9092:9092"
    environment:
      KAFKA_BROKER_ID: 1
      KAFKA_ZOOKEEPER_CONNECT: zookeeper:2181
      KAFKA_LISTENERS: PLAINTEXT://0.0.0.0:9092
      KAFKA_ADVERTISED_LISTENERS: PLAINTEXT://localhost:9092
      KAFKA_OFFSETS_TOPIC_REPLICATION_FACTOR: 1

  mysql-source:
    image: mysql:8.0
    environment:
      MYSQL_ROOT_PASSWORD: root
      MYSQL_DATABASE: company
    command: >
      --server-id=1
      --log-bin=mysql-bin
      --binlog-format=ROW
    ports:
      - "3306:3306"

  mysql-target:
    image: mysql:8.0
    environment:
      MYSQL_ROOT_PASSWORD: root
    ports:
      - "3307:3306"

  connect:
    image: debezium/connect:2.5
    depends_on:
      - kafka
      - mysql-source
    ports:
      - "8083:8083"
    environment:
      BOOTSTRAP_SERVERS: kafka:9092
      GROUP_ID: 1
      CONFIG_STORAGE_TOPIC: connect_configs
      OFFSET_STORAGE_TOPIC: connect_offsets
      STATUS_STORAGE_TOPIC: connect_status

Start everything:

docker compose up -d

Give it ~30 seconds for services to fully start.

🗄 Step 2 — Create Database and Table (Source)

Because MySQL is running inside Docker, we execute commands using Docker.

docker compose exec -T mysql-source mysql -uroot -proot <<EOF
CREATE DATABASE IF NOT EXISTS company;
USE company;

CREATE TABLE IF NOT EXISTS employees (
    id INT PRIMARY KEY AUTO_INCREMENT,
    name VARCHAR(100),
    email VARCHAR(100),
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);
EOF

docker compose exec -T mysql-target mysql -uroot -proot <<EOF
CREATE DATABASE IF NOT EXISTS company;
USE company;

DROP TABLE IF EXISTS employees;

CREATE TABLE employees (
    id INT PRIMARY KEY,
    name VARCHAR(100),
    email VARCHAR(100),
    created_at TIMESTAMP NULL
);
EOF

Insert some sample data:

docker compose exec mysql-source mysql -uroot -proot -e "
USE company;
INSERT INTO employees(name,email)
VALUES ('John Doe','john@example.com');
"

🔌 Step 3 — Configure Debezium Source Connector

This connector reads MySQL binlog and publishes events into Kafka.

curl -X POST http://localhost:8083/connectors \
-H "Content-Type: application/json" \
-d '{
  "name": "mysql-connector",
  "config": {
    "connector.class": "io.debezium.connector.mysql.MySqlConnector",
    "database.hostname": "mysql-source",
    "database.port": "3306",
    "database.user": "root",
    "database.password": "root",
    "database.server.id": "184054",
    "topic.prefix": "dbserver1",
    "database.include.list": "company",
    "table.include.list": "company.employees",
    "schema.history.internal.kafka.bootstrap.servers": "kafka:9092",
    "schema.history.internal.kafka.topic": "schema-changes.company",

    "transforms": "unwrap",
    "transforms.unwrap.type": "io.debezium.transforms.ExtractNewRecordState"
  }
}'

Kafka topic created:

dbserver1.company.employees

🎯 Step 4 — Configure Sink Connector (Target MySQL)

Create target database first:

docker compose exec mysql-target mysql -uroot -proot -e "
CREATE DATABASE IF NOT EXISTS company;
"

Then create the sink connector:

curl -X POST http://localhost:8083/connectors \
-H "Content-Type: application/json" \
-d '{
  "name": "mysql-sink",
  "config": {
    "connector.class": "io.debezium.connector.jdbc.JdbcSinkConnector",
    "topics": "dbserver1.company.employees",

    "connection.url": "jdbc:mysql://mysql-target:3306/company",
    "connection.username": "root",
    "connection.password": "root",

    "insert.mode": "upsert",
    "delete.enabled": "true",
    "primary.key.mode": "record_key",
    "primary.key.fields": "id",

    "auto.create": "true",
    "auto.evolve": "true",
    "table.name.format": "employees"
  }
}'

⚠️ Important — Restart Connector if Needed

Sometimes connectors fail initially due to schema timing or table issues.

Restart connector:

curl -X POST \
"http://localhost:8083/connectors/mysql-sink/restart?includeTasks=true"

Check status:

curl http://localhost:8083/connectors/mysql-sink/status

This is completely normal when working with Kafka Connect.

🧪 Step 5 — Test Real-Time Replication

Insert

docker compose exec mysql-source mysql -uroot -proot -e "
USE company;
INSERT INTO employees(name,email)
VALUES ('Alice','alice@test.com');
"

Update

docker compose exec mysql-source mysql -uroot -proot -e "
USE company;
UPDATE employees
SET name='Updated User'
WHERE id=1;
"

Delete

docker compose exec mysql-source mysql -uroot -proot -e "
USE company;
DELETE FROM employees
WHERE id=2;
"

📥 Verify Data in Target

docker compose exec mysql-target mysql -uroot -proot -e "
USE company;
SELECT * FROM employees;
"

If data doesn’t appear immediately:

Wait a few seconds
Restart connector
Try again

🧠 How It Works Internally

MySQL writes change to binlog
Debezium reads binlog
Kafka stores event
Sink connector consumes event
JDBC writes to target DB

All within seconds.

⚠️ Lessons Learned

During setup we faced:

Connector schema issues
Table mapping problems
Sink auto-creation failures
Connector crashes

Key learnings:

Always unwrap Debezium events
Pre-create tables in production
Restart connector tasks when failed
Understand topic naming

🚀 Production Best Practices

Use Schema Registry
Enable monitoring
Use DLQ
Use migration tools
Secure credentials

✅ Conclusion

CDC enables real-time data movement with minimal overhead.

Debezium + Kafka provides:

Scalability
Reliability
Low latency
Event-driven architecture

This pattern is widely used in modern distributed systems.

🙌 Final Thoughts

If you are working in:

Data Engineering
DevOps
Backend Systems
Platform Engineering

Learning CDC is extremely valuable.

⭐ If you enjoyed this article, feel free to connect and share your feedback!

Zero‑Downtime Deployments on AKS with Azure Application Gateway Ingress Controller (AGIC)

POTHURAJU JAYAKRISHNA YADAV — Fri, 23 Jan 2026 15:10:27 +0000

Background

While deploying applications on Azure Kubernetes Service (AKS) behind Azure Application Gateway Ingress Controller (AGIC), I repeatedly faced brief but noticeable downtime during deployments.

The issue was not with Kubernetes itself, but with how AGIC updates backend pool IPs when pods are replaced during a deployment.

By default, during a rollout:

Old pods are terminated
New pods come up with new IPs
AGIC takes around 30 seconds (sometimes more) to detect and update these new pod IPs in Application Gateway

During this window, Application Gateway may still route traffic to terminating pods → resulting in 5xx errors or downtime.

The Root Cause

Let’s understand what was happening internally:

Kubernetes starts terminating old pods
Pods are removed from Endpoints
AGIC needs time to:

Detect endpoint changes
Update Application Gateway backend pool
Push config updates
1. Meanwhile, traffic is still flowing

If pods terminate too fast, Application Gateway temporarily has no healthy backend, causing downtime.

The Strategy That Fixed It

After digging into this and testing a few approaches in production, I implemented three small but very effective changes in my Deployment YAML:

1. RollingUpdate Strategy

strategy:
  type: RollingUpdate
  rollingUpdate:
    maxSurge: 1
    maxUnavailable: 0

Why this matters:

Ensures at least one pod is always available
New pod comes up before old pod is removed

2. Increased Termination Grace Period

spec:
  terminationGracePeriodSeconds: 300

Why this matters:

Gives Kubernetes 5 minutes before force‑killing the pod
Allows existing connections to complete
Buys time for AGIC to update backend pool

3. preStop Hook to Delay Pod Shutdown

lifecycle:
  preStop:
    exec:
      command: ["/bin/sh", "-c", "sleep 280"]

Why this matters:

Pod stays in Terminating state for ~280 seconds
Application Gateway continues routing traffic safely
AGIC finishes updating new pod IPs before traffic stops

What Changed After This?

After applying this configuration in production, the difference was immediately noticeable:

✅ No more deployment‑time downtime

✅ Zero 502 / 504 errors from Application Gateway

✅ Smooth traffic transition between old and new pods

✅ AGIC gets enough time to sync backend pool changes

Even during peak traffic, deployments became completely seamless.

Why This Is Important for AGIC Users

AGIC is not instant. It operates asynchronously and depends on:

Kubernetes endpoint updates
ARM / Application Gateway config propagation

So fast pod termination = broken traffic.

This pattern ensures:

“Never kill a pod until the load balancer has fully learned about the new one.”

Final Thoughts (From Real Experience)

If you are using:

AKS
Azure Application Gateway
AGIC

and facing deployment‑time downtime, this approach is mandatory, not optional.

Kubernetes already gives us the right tools — we just need to tune them correctly based on how cloud load balancers like Application Gateway behave in the real world.

Happy deploying 🚀

Let me know if you want a version with:

Diagrams
AGIC internals
Comparison with NGINX ingress
Real production metrics

Reducing Sentry APM Costs in FastAPI by Sending Only What Matters

POTHURAJU JAYAKRISHNA YADAV — Thu, 08 Jan 2026 06:41:51 +0000

When I first enabled managed Sentry APM for a FastAPI application, the visibility felt amazing.
Every request was traced. Every endpoint had performance data.

But that excitement didn’t last long.

After a few days in production, I realized something important:

Most of my Sentry APM usage was coming from perfectly healthy, fast requests that I never looked at again.

Successful GETs, quick POSTs, OpenAPI calls — all of them were being sent to Sentry, eating up the quota and increasing cost without providing real value.

So instead of scaling my Sentry plan, I chose a different approach:

👉 Send fewer transactions, but send the right ones.

The Real Problem with Default APM

By default, Sentry APM is very generous:

Every request becomes a transaction
Even sub-second successful calls are recorded
Docs and schema endpoints are also traced

For high-traffic APIs, this quickly turns into:

Large transaction volume
Faster quota exhaustion
Paying for noise instead of insight

In reality, I only needed visibility into:

Requests that fail (5xx)
Requests that are slow
Anything abnormal or risky

Everything else was just background noise.

The Cost-Saving Strategy

I defined very simple rules:

Always Send to Sentry

Any request returning 5xx
Any request taking more than 5 seconds

Drop from Sentry

Fast GET / POST / PUT requests
Successful requests completing under 3 seconds
/docs and /openapi.json endpoints

This keeps Sentry focused on problems, not traffic volume.

Why Two Middlewares Are Required

This part is important and often misunderstood.

app.add_middleware(SentryAsgiMiddleware)
app.add_middleware(TimingMiddleware)

These two middlewares do different jobs, and both are required.

SentryAsgiMiddleware – Enables APM

SentryAsgiMiddleware is what actually:

Starts and finishes Sentry transactions
Hooks into the ASGI request lifecycle
Sends performance data to Sentry

Without this middleware:

No transactions are created
before_send_transaction is never called
APM simply does not work

In short:

No SentryAsgiMiddleware = No APM

TimingMiddleware – Adds Intelligence

The second middleware is custom.

It measures the real execution time of each request and attaches it to the Sentry scope.

class TimingMiddleware(BaseHTTPMiddleware):
    async def dispatch(self, request: Request, call_next):
        start_time = time.time()
        response = await call_next(request)
        duration = time.time() - start_time

        with sentry_sdk.configure_scope() as scope:
            scope.set_extra("duration", duration)

        return response

Why this is needed:

Execution time is required to decide whether a request is “important”
Sentry’s internal timing isn’t easily usable for filtering
Without this, cost-control logic becomes guesswork

Think of it this way:

SentryAsgiMiddleware is the pipeline
TimingMiddleware is the brain

Filtering Transactions Before They Are Sent

Sentry provides a hook called before_send_transaction.
This runs just before a transaction is sent to Sentry and allows you to drop it.

This is where the cost optimization happens.

def before_send_transaction(event, hint):
    transaction_name = event.get("transaction", "")
    request_method = event.get("request", {}).get("method", "")
    status_code = event.get("contexts", {}).get("response", {}).get("status_code", 0)

    duration = event.get("extra", {}).get("duration")

    # Ignore docs and schema
    if "/docs" in transaction_name or "/openapi.json" in transaction_name:
        return None

    # Always send server errors
    if 500 <= status_code <= 599:
        return event

    # Send slow requests
    if duration and duration > 5:
        return event

    # Drop fast successful requests
    if request_method in ["GET", "POST", "PUT"] \
       and 200 <= status_code < 400 \
       and duration and duration < 3:
        return None

    return event

If this function returns:

event → transaction is sent
None → transaction is dropped

Simple, predictable, and fully under your control.

Initializing Sentry with Custom Filtering

sentry_sdk.init(
    dsn="SENTRY_DSN",
    send_default_pii=True,
    traces_sample_rate=1.0,
    before_send_transaction=before_send_transaction,
)

Instead of relying on random sampling, this approach gives deterministic filtering based on real behavior.

What Changed After This

Lower Cost

Transaction volume dropped sharply.
Sentry usage slowed down immediately.

Cleaner Dashboards

Only slow or failing requests appeared.
Debugging became easier, not harder.

Better Signal

Every transaction in Sentry now means:

“This is worth looking at.”

When This Approach Makes Sense

This works best when:

Your API traffic is high
Most requests are successful and fast
You care more about issues than metrics

If you want every request traced forever, this is not the right approach.
If you want useful observability without burning money, it absolutely is.

Final Thoughts

APM should help you find problems, not create new ones in your billing dashboard.

By combining:

SentryAsgiMiddleware
A simple timing middleware
before_send_transaction

You turn Sentry from:

“collect everything”
into
“collect what actually matters”

And that small change makes a huge difference in real production systems.

Automating S3 Data Retention by Prefix Using Python (DevOps Automation Story)

POTHURAJU JAYAKRISHNA YADAV — Thu, 08 Jan 2026 06:25:05 +0000

In many production systems, object storage slowly becomes a dumping ground.

Logs, reports, media files, exports — everything lands in the same S3 bucket, but not all data needs to live forever. The real challenge is not deleting data, but deleting the right data at the right time, without relying on manual processes.

This post explains how I automated folder-level retention policies in Amazon S3 using Python, turning a repetitive console task into a clean, auditable automation.

The scenario (fictional but realistic)

Imagine a shared S3 bucket used by multiple internal teams:

company-shared-storage/
├── analytics/
├── audit-logs/
├── temp-exports/
├── media-processing/
└── legal-archive/

Each folder has a different data lifecycle requirement:

> Prefix    Retention
> analytics/    3 months
> audit-logs/   6 months
> temp-exports/ 30 days
> media-processing/ 90 days
> legal-archive/    retain forever

Managing this manually in the AWS Console does not scale and is easy to misconfigure.

Why automation was necessary

Manually configuring lifecycle rules:

Requires repetitive console work
Is difficult to review and audit
Does not fit infrastructure-as-code practices
Is error-prone during changes

So instead of treating retention as a one-time setup, I treated it as automation logic.

Important constraints to understand first

Before writing any automation, it’s critical to understand how S3 behaves:

S3 lifecycle expiration is based on object creation time
It does not track last access or last modification
S3 has no real folders — only prefixes
Lifecycle rules delete objects, not folders
Buckets without versioning only need “expire current versions”

Designing automation without knowing this leads to surprises later.

Automation design approach

The goal was simple:

Define retention rules as data
Convert retention into lifecycle policies programmatically
Skip prefixes that should never be touched
Make the process repeatable and reviewable

Retention rules were expressed in a simple mapping structure, not hardcoded logic.

Python automation example

import boto3

bucket_name = "company-shared-storage"
profile = "prod-profile"

retention_map = {
    "analytics/": 90,
    "audit-logs/": 180,
    "temp-exports/": 30,
    "media-processing/": 90,
    "legal-archive/": None
}

session = boto3.Session(profile_name=profile)
s3 = session.client("s3")

rules = []

for prefix, days in retention_map.items():
    if not days:
        continue

    rules.append({
        "ID": f"expire-{prefix.strip('/')}-{days}-days",
        "Status": "Enabled",
        "Filter": {"Prefix": prefix},
        "Expiration": {"Days": days}
    })

if rules:
    s3.put_bucket_lifecycle_configuration(
        Bucket=bucket_name,
        LifecycleConfiguration={"Rules": rules}
    )

What this automation achieves

Objects under analytics/ are deleted after 90 days
Objects under audit-logs/ are deleted after 180 days
Objects under legal-archive/ are never deleted
Overwriting an object resets its expiration timer
Lifecycle execution is handled asynchronously by S3 No human intervention required after setup.

Why this is real automation

This approach:

Removes manual AWS Console dependency
Makes retention policy code-driven
Allows easy updates through version control
Reduces the risk of accidental data loss
Aligns with Infrastructure-as-Code principles

Retention stops being “someone’s responsibility” and becomes system behavior.

Key lessons learned

Lifecycle policies are based on creation time, not inactivity
Prefix-based retention works well when automation-driven
Empty retention should explicitly mean “no rule”
Lifecycle rules overwrite existing configuration — automation must be intentional

Where this can be extended

This automation can easily evolve into:

Reading retention from a CSV or database
A scheduled compliance check
Validation against existing lifecycle rules
Integration into CI/CD pipelines

Final takeaway

S3 lifecycle policies are powerful, but their real value comes when they are automated, not manually configured.

Small automations like this reduce operational overhead and prevent long-term storage sprawl — which is exactly what good DevOps is about.