Production Three-Tier Microservices on AWS EKS

Architecture

About the Project

In this project, we will deploy a three-tier application (React frontend, Flask backend, RDS PostgreSQL database) on AWS EKS. We’ll use Docker for containerisation, GitHub Actions and ECR for CI/CD, ArgoCD for GitOps, and Prometheus/Grafana for observability.

We will use an AWS ALB Ingress Controller to expose the application and External Services to connect to our RDS database.

Prerequisites

I’ll assume you have basic knowledge of Docker, Kubernetes, and AWS services. You will need to install eksctl, aws cli, kubectl, docker and terraform on your local machine.

Cloning the Repository

First, clone the repository containing all the code and configuration files:

git clone https://github.com/wegoagain-dev/3-tier-eks.git
cd 3-tier-eks

Creating the EKS Cluster

⚠️ NOTE: Ensure your AWS CLI is configured. EKS costs ~$0.10/hour, so remember to delete resources when finished!

We will use eksctl with a cluster-config.yaml file to provision our cluster.

Run the following in your terminal:

eksctl create cluster -f cluster-config.yaml

The cluster-config.yaml (included in the repo) looks like this:

1
apiVersion: eksctl.io/v1alpha5
2
kind: ClusterConfig
3

4
metadata:
5
  name: three-tier
6
  region: eu-west-2
7
  version: "1.31"
8

9
managedNodeGroups:
10
  - name: standard-workers
11
    instanceType: t3.medium
12
    minSize: 1
13
    maxSize: 3
14
    desiredCapacity: 2
15
    iam:
16
      withAddonPolicies:
17
        imageBuilder: true
18
        albIngress: true
19
        cloudWatch: true

It can take 15-20 minutes to create the cluster. once done, verify it:

# Check the status of the EKS cluster
aws eks list-clusters

kubectl command should be automatically configured by eksctl. Run these commands to ensure you can see the nodes in your cluster:

# Check the nodes in the cluster
kubectl get namespaces #list all namespaces
kubectl get nodes #list all nodes
kubectl get pods -A #list all pods in all namespaces
kubectl get services -A #list all services in all namespaces

Hopefully should all be up and running.

For this project we are using a React frontend, a Flask backend that connects to a PostgreSQL database.

Creating PostgreSQL RDS Database (Terraform)

Instead of manually creating the database, config and secrets, we will use Terraform to automate everything. We’ll split our configuration into logical files for a “Production Grade” structure.

1. Navigate to the terraform directory:

cd terraform

2. Review provider.tf:

This file configures the AWS and Kubernetes providers. Notably, it uses the aws_eks_cluster data source to dynamically fetch cluster details.

1
terraform {
2
  required_version = ">= 1.0"
3

4
  required_providers {
5
    aws = {
6
      source  = "hashicorp/aws"
7
      version = "~> 5.0"
8
    }
9
    kubernetes = {
10
      source  = "hashicorp/kubernetes"
11
      version = "~> 2.23"
12
    }
13
    helm = {
14
      source  = "hashicorp/helm"
15
      version = "~> 2.11"
16
    }
17
  }
18
}
19

20
provider "aws" {
21
  region = var.aws_region
22
}
23

24
# 1. Ask AWS for the cluster details (Dynamic Lookup)
25
data "aws_eks_cluster" "cluster" {
26
  name = var.cluster_name
27
}
28

29
data "aws_eks_cluster_auth" "auth" {
30
  name = var.cluster_name
31
}
32

33
# 2. Configure Kubernetes Provider (Uses the AWS API, not a file)
34
provider "kubernetes" {
35
  host                   = data.aws_eks_cluster.cluster.endpoint
36
  cluster_ca_certificate = base64decode(data.aws_eks_cluster.cluster.certificate_authority[0].data)
37
  token                  = data.aws_eks_cluster_auth.auth.token
38
}
39

40
# 3. Configure Helm Provider
41
provider "helm" {
42
  kubernetes {
43
    host                   = data.aws_eks_cluster.cluster.endpoint
44
    cluster_ca_certificate = base64decode(data.aws_eks_cluster.cluster.certificate_authority[0].data)
45
    token                  = data.aws_eks_cluster_auth.auth.token
46
  }
47
}

3. Review variables.tf:

Variables allow us to make our configuration reusable.

1
variable "git_repo_url" {
2
  description = "GitHub repository URL for ArgoCD to watch"
3
  type        = string
4
  default     = "https://github.com/wegoagain-dev/3-tier-eks.git" # Change this or pass via -var
5
}
6

7
# Variable for your GitHub Repo (e.g., "your-user/your-repo")
8
variable "github_repo" {
9
  description = "The GitHub repository path (e.g., 'wegoagain-dev/3-tier-eks')"
10
  type        = string
11
  default     = "wegoagain-dev/3-tier-eks" # Change this or pass via -var
12
}
13

14
variable "cluster_name" {
15
  description = "EKS cluster name"
16
  type        = string
17
  default     = "three-tier"
18
}
19

20
variable "aws_region" {
21
  description = "AWS region"
22
  type        = string
23
  default     = "eu-west-2"
24
}
25

26
variable "argocd_chart_version" {
27
  description = "ArgoCD Helm chart version"
28
  type        = string
29
  default     = "5.51.6"
30
}

4. Review rds.tf (Database & Network):

This file handles the creation of the RDS instance, security groups, and subnets.

1
# 1. Get EKS Cluster VPC
2
data "aws_vpc" "eks_vpc" {
3
  id = data.aws_eks_cluster.cluster.vpc_config[0].vpc_id
4
}
5

6
# 2. Get Private Subnets
7
data "aws_subnets" "private" {
8
  filter {
9
    name   = "vpc-id"
10
    values = [data.aws_vpc.eks_vpc.id]
11
  }
12
  filter {
13
    name   = "tag:kubernetes.io/role/internal-elb"
14
    values = ["1"]
15
  }
16
}
17

18
# 3. Get EKS Node Security Group
19
data "aws_security_groups" "eks_nodes" {
20
  filter {
21
    name   = "vpc-id"
22
    values = [data.aws_vpc.eks_vpc.id]
23
  }
24
  filter {
25
    name   = "tag:aws:eks:cluster-name"
26
    values = [var.cluster_name]
27
  }
28
}
29

30
# 4. Create Security Group for RDS
31
resource "aws_security_group" "rds_sg" {
32
  name        = "rds-security-group"
33
  description = "Allow inbound traffic from EKS nodes"
34
  vpc_id      = data.aws_vpc.eks_vpc.id
35

36
  ingress {
37
    from_port       = 5432
38
    to_port         = 5432
39
    protocol        = "tcp"
40
    security_groups = [data.aws_security_groups.eks_nodes.ids[0]]
41
  }
42

43
  egress {
44
    from_port   = 0
45
    to_port     = 0
46
    protocol    = "-1"
47
    cidr_blocks = ["0.0.0.0/0"]
48
  }
49
}
50

51
# 5. Create DB Subnet Group
52
resource "aws_db_subnet_group" "default" {
53
  name       = "three-tier-subnet-group"
54
  subnet_ids = data.aws_subnets.private.ids
55
  tags = {
56
    Name = "My DB subnet group"
57
  }
58
}
59

60
# 6. Generate Random Password
61
resource "random_password" "db_password" {
62
  length           = 16
63
  special          = true
64
  override_special = "_%@"
65
}
66

67
# 7. Create RDS Instance
68
resource "aws_db_instance" "default" {
69
  allocated_storage      = 20
70
  storage_type           = "gp2"
71
  engine                 = "postgres"
72
  engine_version         = "15"
73
  instance_class         = "db.t3.micro"
74
  db_name                = "devops_learning"
75
  username               = "postgresadmin"
76
  password               = random_password.db_password.result
77
  skip_final_snapshot    = true
78
  db_subnet_group_name   = aws_db_subnet_group.default.name
79
  vpc_security_group_ids = [aws_security_group.rds_sg.id]
80
  multi_az               = false # production turn on (jus to save cost)
81
  apply_immediately      = true
82
}

5. Review k8s.tf (Kubernetes Resources):

This file creates the Kubernetes namespace, secrets, ExternalName service, and ConfigMap.

1
# 8. Create Namespace
2
resource "kubernetes_namespace" "app" {
3
  metadata {
4
    name = "3-tier-app-eks"
5
  }
6
}
7

8
# 9. Create Kubernetes Secret (AUTOMATED)
9
resource "kubernetes_secret" "database_secret" {
10
  metadata {
11
    name      = "database-secret"
12
    namespace = kubernetes_namespace.app.metadata[0].name
13
  }
14

15
  data = {
16
    DATABASE_URL = "postgresql://${aws_db_instance.default.username}:${random_password.db_password.result}@${aws_db_instance.default.address}:${aws_db_instance.default.port}/${aws_db_instance.default.db_name}"
17
    DB_PASSWORD  = random_password.db_password.result
18
  }
19

20
  type = "Opaque"
21
}
22

23
# 10. Create ExternalName Service (AUTOMATED)
24
resource "kubernetes_service" "postgres_db" {
25
  metadata {
26
    name      = "postgres-db"
27
    namespace = kubernetes_namespace.app.metadata[0].name
28
  }
29
  spec {
30
    type          = "ExternalName"
31
    external_name = aws_db_instance.default.address
32
    port {
33
      port = 5432
34
    }
35
  }
36
}
37

38
# 11. Create ConfigMap (AUTOMATED)
39
resource "kubernetes_config_map" "app_config" {
40
  metadata {
41
    name      = "app-config"
42
    namespace = kubernetes_namespace.app.metadata[0].name
43
  }
44

45
  data = {
46
    DB_NAME     = "devops_learning"
47
    BACKEND_URL = "http://backend:8000"
48
  }
49
}

6. Apply the Infrastructure:

# Initialise Terraform
terraform init

# Apply configuration
terraform apply

Terraform will now create everything needed for your environment: RDS Instance, Namespace, Secret, Service, and ConfigMap.

GitHub Actions & ECR setup

We need to set up OIDC to allow GitHub Actions to push to AWS ECR without hardcoding long-term credentials. Instead of manual AWS CLI commands, we will add this to our Terraform stack.

1
# 1. Create OIDC Provider for GitHub Actions
2
resource "aws_iam_openid_connect_provider" "github" {
3
  url = "https://token.actions.githubusercontent.com"
4

5
  client_id_list = [
6
    "sts.amazonaws.com",
7
  ]
8

9
  thumbprint_list = [
10
    "6938fd4d98bab03faadb97b34396831e3780aea1", # GitHub's Thumbprint
11
    "1c58a3a8518e8759bf075b76b750d4f2df264fcd"  # Backup thumbprint just in case
12
  ]
13
}
14

15
# 2. Create IAM Role for GitHub Actions
16
resource "aws_iam_role" "github_actions" {
17
  name = "GitHubActionsECR"
18

19
  assume_role_policy = jsonencode({
20
    Version = "2012-10-17"
21
    Statement = [
22
      {
23
        Action = "sts:AssumeRoleWithWebIdentity"
24
        Effect = "Allow"
25
        Principal = {
26
          Federated = aws_iam_openid_connect_provider.github.arn
27
        }
28
        Condition = {
29
          StringLike = {
30
            "token.actions.githubusercontent.com:sub" = "repo:${var.github_repo}:*"
31
          }
32
          StringEquals = {
33
            "token.actions.githubusercontent.com:aud" = "sts.amazonaws.com"
34
          }
35
        }
36
      },
37
    ]
38
  })
39
}
40

41
# 3. Attach ECR PowerUser Policy
42
resource "aws_iam_role_policy_attachment" "ecr_poweruser" {
43
  role       = aws_iam_role.github_actions.name
44
  policy_arn = "arn:aws:iam::aws:policy/AmazonEC2ContainerRegistryPowerUser"
45
}
46

47
output "github_actions_role_arn" {
48
  value = aws_iam_role.github_actions.arn
49
}

# Apply again to create the OIDC resources
terraform apply

Configuration & Deployment Preparation

Now that the infrastructure is ready, we need to prepare our application for deployment.

1. Set up ECR and CI/CD

1. Create frontend and backend repositories in AWS ECR.
2. Update the .github/workflows/ci.yml file in your repo with:
   • Your AWS Region
   • Your ECR Repository Names
   • The IAM Role ARN you created in the previous step.
3. Push these changes to GitHub to trigger the build pipeline.

2. Update Kubernetes Manifests

All deployment manifests are located in the k8s/ folder.

⚠️ CRITICAL STEP: Update Image References

The files k8s/backend.yaml, k8s/frontend.yaml, and k8s/migration_job.yaml are currently configured with placeholder or private ECR URIs.

Action: Open these files and replace the existing image URI (e.g., 373317459404.dkr.ecr.eu-west-2.amazonaws.com) with your own ECR URI: <your-account-id>.dkr.ecr.<region>.amazonaws.com

If you skip this, your pods will fail with ImagePullBackOff.

Verification

Since we used Terraform, the Namespace, Database Secret, Database Service, and Application ConfigMap have already been created for us!

Let’s verify that everything is set up correctly:

# 1. Check if the namespace exists
kubectl get namespace 3-tier-app-eks

# 2. Check if the secret exists (do NOT print it)
kubectl get secret database-secret -n 3-tier-app-eks

# 3. Check if the ExternalName service is pointing to your RDS
kubectl get svc postgres-db -n 3-tier-app-eks

# 4. Check if the ConfigMap exists
kubectl get configmap app-config -n 3-tier-app-eks

You should see all resources listed. This means Terraform successfully automated the “glue” between AWS and Kubernetes.

To verify connectivity, we can spin up a temporary pod:

kubectl run pg-connection-test --rm -it --image=postgres:14 --namespace=3-tier-app-eks -- bash

# Inside the pod, connect with SSL:
PGSSLMODE=require psql -h postgres-db -p 5432 -U postgresadmin -d devops_learning
# Enter password (use 'terraform output -raw db_password' to see it if needed). Type 'exit' to leave.

Note: RDS PostgreSQL 15 requires SSL by default. We use PGSSLMODE=require to enable SSL in the connection.

Running database migrations

In this project theres a database migration that needs to be run before deploying the backend service. This is done using a Kubernetes Job, which is a one-time task that runs to completion, this will create database tables and seed data for the application to work correctly.

What a job does is it creates a pod that runs the specified command and then exits. If the command fails, the job will retry until it succeeds or reaches the specified backoff limit.

This command kubectl apply -f migration_job.yaml will create a job that runs the command to apply the database migrations. This command will create the necessary tables and seed data in the RDS PostgreSQL database. Its worth analysing the job manifest to understand what it does and how it works. this is where the secrets we created earlier will be used to connect to the database. its better than hardcoding the database credentials in the job manifest, because it allows you to change the credentials without modifying the job manifest.

(dont forget to modify the file to use your own backend image)

The job will use the DATABASE_URL from the database-secret to authenticate.

#run these one by one in k8s/ folder
kubectl apply -f migration_job.yaml
kubectl get job -A
kubectl get pods -n 3-tier-app-eks

Run kubectl describe pod database-migration-<name> -n 3-tier-app-eks and you should see it completed succesfully

Backend and Frontend services

Now lets deploy the backend and frontend services. The backend service is a Flask application that connects to the RDS PostgreSQL database, and the frontend service is a React application that communicates with the backend service.

Read the manifest files for the backend and frontend services to understand what they do and how they work.

Backend Environment Variables: The backend uses the DATABASE_URL from our database-secret to connect to RDS:

1
env:
2
  - name: DATABASE_URL
3
    valueFrom:
4
      secretKeyRef:
5
        name: database-secret
6
        key: DATABASE_URL
7
  - name: ALLOWED_ORIGINS
8
    value: "*"

Frontend Environment Variables: The frontend uses the BACKEND_URL from our app-config ConfigMap:

1
env:
2
  - name: BACKEND_URL
3
    valueFrom:
4
      configMapKeyRef:
5
        name: app-config
6
        key: BACKEND_URL

Apply the deployments:

# apply the backend service manifest
kubectl apply -f backend.yaml
# apply the frontend service manifest
kubectl apply -f frontend.yaml
# check the status of the pods
kubectl get deployment -n 3-tier-app-eks
kubectl get svc -n 3-tier-app-eks

Accessing the application

At the minute we havent created ingress resources to expose the application to the internet. To access the application temporarily, we will port-forward the frontend and backend services to our local machine. This will allow us to access the application using localhost and a specific port. Open two terminal windows, one for the backend service and one for the frontend service. In the first terminal window, run the following command to port-forward the backend service: We need to open new terminals because the port-forward command will block the terminal until you stop it with CTRL+C.

# port-forward the backend service to localhost:8000
kubectl port-forward svc/backend 8000:8000 -n 3-tier-app-eks
# port-forward the frontend service to localhost:8080
kubectl port-forward svc/frontend 8080:80 -n 3-tier-app-eks

you can access the backend service at http://localhost:8000/api/topics in the browser or curl http://localhost:8000/api/topics in the terminal.

you can access the frontend service at http://localhost:8080 in the browser. The frontend service will communicate with the backend service to fetch data and display it.

this is a devops quiz application that you can use. the seed data created some samples, in the manage questions you can add more questions and answers. the 3-tier-app-eks/backend/questions-answers includes some csv files that you can use to import questions and answers into the application. You can also add your own questions and answers using the frontend interface.

Time to implement Ingress

We need an Ingress Controller to manage external access (HTTP/HTTPS) to our services. We’ll use the AWS Load Balancer Controller, managed via Terraform.

Review lb_controller.tf:

This file uses Terraform to install the AWS Load Balancer Controller via Helm. Since we created our cluster with eksctl and enabled albIngress: true in the cluster configuration, the necessary IAM permissions are already in place.

1
resource "helm_release" "aws_load_balancer_controller" {
2
  name       = "aws-load-balancer-controller"
3
  repository = "https://aws.github.io/eks-charts"
4
  chart      = "aws-load-balancer-controller"
5
  namespace  = "kube-system"
6
  version    = "1.7.1"
7

8
  set {
9
    name  = "clusterName"
10
    value = var.cluster_name
11
  }
12

13
  set {
14
    name  = "serviceAccount.create"
15
    value = "true"
16
  }
17

18
  set {
19
    name  = "serviceAccount.name"
20
    value = "aws-load-balancer-controller"
21
  }
22
}

Apply the Terraform configuration:

cd terraform
terraform apply -auto-approve

Ingress Manifest

Now, apply the ingress manifest. This tells the controller to route traffic:

• /api -> Backend Service
• / -> Frontend Service

kubectl apply -f ingress.yaml

The ingress.yaml file:

1
apiVersion: networking.k8s.io/v1
2
kind: IngressClass
3
metadata:
4
  name: alb
5
spec:
6
  controller: ingress.k8s.aws/alb
7
---
8
apiVersion: networking.k8s.io/v1
9
kind: Ingress
10
metadata:
11
  name: three-tier-ingress
12
  namespace: 3-tier-app-eks
13
  annotations:
14
    alb.ingress.kubernetes.io/scheme: internet-facing
15
    alb.ingress.kubernetes.io/target-type: ip
16
spec:
17
  ingressClassName: alb
18
  rules:
19
    - http:
20
        paths:
21
          - path: /api
22
            pathType: Prefix
23
            backend:
24
              service:
25
                name: backend
26
                port:
27
                  number: 8000
28
          - path: /
29
            pathType: Prefix
30
            backend:
31
              service:
32
                name: frontend
33
                port:
34
                  number: 80

Verify it’s working (it takes a few minutes for the ALB to provision):

# Check Ingress status (Look for the ADDRESS field)
kubectl get ingress -n 3-tier-app-eks

# Debugging: Check Controller logs
kubectl logs -n kube-system -l app.kubernetes.io/name=aws-load-balancer-controller

It may take a few minutes for the ALB to be provisioned and the DNS name to be available. Once it is available, you can access it by copying the DNS name from the ingress command and pasting it in the browser.

Here’s a video demo: (best in full screen)

Complete CI/CD using ArgoCD (GitOps)

ArgoCD continuously syncs your GitHub repository with your Kubernetes cluster.

1. Install ArgoCD (Terraform)

Review argocd.tf:

1
resource "helm_release" "argocd" {
2
  name             = "argocd"
3
  repository       = "https://argoproj.github.io/argo-helm"
4
  chart            = "argo-cd"
5
  namespace        = "argocd"
6
  create_namespace = true
7
  version          = var.argocd_chart_version
8

9
  set {
10
    name  = "server.service.type"
11
    value = "ClusterIP"
12
  }
13
  set {
14
    name  = "redis-ha.enabled"
15
    value = "false"
16
  }
17
}

Apply the changes:

terraform apply

To access the UI:

# Wait for pods
kubectl get pods -n argocd
# then access UI
kubectl port-forward svc/argocd-server -n argocd 9000:443

Access via https://localhost:9000. Accept the self-signed certificate warning.

2. Get Password & Login
Username: admin

kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath="{.data.password}" | base64 -d; echo

3. Deploy the Application
We’ll use an Application CRD to tell ArgoCD what to sync.

⚠️ CRITICAL STEP: Update argocd-app.yaml with YOUR GitHub repoURL before applying.

kubectl apply -f argocd-app.yaml

Check the UI—you should see your app syncing!

Adding Monitoring (Prometheus & Grafana)

We’ll use the kube-prometheus-stack Helm chart to install a full monitoring suite, managed via Terraform.

Review monitoring.tf:

This file uses Terraform to install Prometheus and Grafana via the kube-prometheus-stack Helm chart.

1
resource "helm_release" "kube_prometheus_stack" {
2
  name             = "prometheus"
3
  repository       = "https://prometheus-community.github.io/helm-charts"
4
  chart            = "kube-prometheus-stack"
5
  namespace        = "monitoring"
6
  create_namespace = true
7
  version          = "56.6.2"
8

9
  # Allow Prometheus to discover all ServiceMonitors across namespaces
10
  set {
11
    name  = "prometheus.prometheusSpec.serviceMonitorSelectorNilUsesHelmValues"
12
    value = "false"
13
  }
14

15
  # Set Grafana admin password
16
  set {
17
    name  = "grafana.adminPassword"
18
    value = "admin123"
19
  }
20

21
  # Optional: Persist Grafana dashboards and data
22
  set {
23
    name  = "grafana.persistence.enabled"
24
    value = "false"
25
  }
26

27
  # Optional: Persist Prometheus data
28
  set {
29
    name  = "prometheus.prometheusSpec.retention"
30
    value = "7d"
31
  }
32
}

Apply the Terraform configuration:

cd terraform
terraform apply -auto-approve

Access Grafana

kubectl port-forward svc/prometheus-grafana -n monitoring 3000:80

Go to http://localhost:3000. Login with admin / admin123.

Explore the pre-built dashboards under Dashboards > General > Kubernetes / Compute Resources.

What’s Next? (Production Enhancements)

To make this project fully enterprise-ready, In the next steps we will add:

• Custom Domain & SSL: Use ExternalDNS to sync Route53 with the Ingress, and AWS Certificate Manager (ACM) to automatically provision free SSL certificates for the ALB.
• Network Security: Implement Kubernetes Network Policies to restrict traffic. For example, allow the Frontend to talk only to the Backend, and the Backend only to the Database, blocking all other internal traffic.
• Auto-Scaling: Configure Horizontal Pod Autoscalers (HPA) to automatically add more backend pods when CPU usage spikes (e.g., above 70%).

Cleanup & Teardown

⚠️ IMPORTANT: Follow these steps in order to avoid unexpected AWS charges and ensure complete resource cleanup.

Step 1: Delete Kubernetes Resources (Optional but Recommended)

First, delete the Ingress to trigger ALB cleanup:

kubectl delete ingress three-tier-ingress -n 3-tier-app-eks

Wait 1-2 minutes for the AWS Load Balancer Controller to clean up the ALB and target groups.

Step 2: Destroy Terraform-Managed Resources

cd terraform
terraform destroy -auto-approve

This will remove:

• RDS PostgreSQL database
• Kubernetes namespace and resources
• ArgoCD installation
• AWS Load Balancer Controller
• Prometheus & Grafana monitoring stack
• IAM roles and OIDC provider for GitHub Actions

Note: If the namespace deletion hangs, you may need to force-delete it (see troubleshooting below).

Step 3: Delete the EKS Cluster

eksctl delete cluster three-tier --region eu-west-2

This will delete:

• EKS control plane
• Managed node groups
• VPC and networking resources
• IAM roles for nodes

Troubleshooting Cleanup Issues

If the ALB won’t delete:

The AWS Load Balancer Controller may leave behind ALBs if the Ingress wasn’t properly deleted. Manually remove them:

# Find the ALB
aws elbv2 describe-load-balancers --region eu-west-2 \
  --query 'LoadBalancers[?contains(LoadBalancerName, `k8s-3tierapp`)].LoadBalancerArn' \
  --output text

# Delete it
aws elbv2 delete-load-balancer --load-balancer-arn <ARN> --region eu-west-2

# Delete target groups (wait 10 seconds after deleting ALB)
aws elbv2 describe-target-groups --region eu-west-2 \
  --query 'TargetGroups[?contains(TargetGroupName, `k8s-3tierapp`)].TargetGroupArn' \
  --output text | xargs -I {} aws elbv2 delete-target-group --target-group-arn {} --region eu-west-2

If namespace deletion hangs:

kubectl delete namespace 3-tier-app-eks --force --grace-period=0

If ArgoCD CRDs remain:

kubectl delete crd applications.argoproj.io applicationsets.argoproj.io appprojects.argoproj.io

Verification

Double-check the AWS Console to ensure all resources are deleted:

• EC2 Dashboard: No running instances, load balancers, or target groups
• RDS Dashboard: No databases
• EKS Dashboard: No clusters
• CloudFormation: No stacks related to eksctl-three-tier
• IAM: No roles starting with eksctl-three-tier or GitHubActionsECR

Estimated monthly cost if left running: ~$100-150 (EKS cluster$73 + RDS $15 + EC2 instances$20-40)