In this guide, we’ll deploy Stan’s Robot Shop, a sample e-commerce application that showcases a three-tier microservices architecture, onto an Amazon EKS (Elastic Kubernetes Service) cluster using Helm charts.

The application is composed of several microservices (~8 in total) and a couple of backend databases, mimicking a realistic production environment. This tutorial covers:

• Project architecture

• AWS infrastructure prerequisites (IAM roles, VPC, ALB Ingress Controller, EBS CSI Driver)

• Helm chart installation on EKS

• Accessing and optionally load testing or monitoring the application

The goal is to provide a comprehensive, step-by-step walkthrough that gets the full system running on AWS, giving you hands-on experience with deploying cloud-native applications on Kubernetes.

🧱 Project Overview & Architecture

Stan’s Robot Shop is a cloud-native application built on a three-tier architecture:

1. Presentation Layer: Web UI

2. Application Logic Layer: Backend microservices

3. Data Layer: Databases and message queues

Rather than a monolithic app, Robot Shop is broken into independent microservices that handle distinct domains such as user registration, product catalog, cart, shipping, and payments. The architecture is both polyglot and microservice-driven, with services written in various languages:

🔷 Tech Stack Overview

• Frontend:

  • AngularJS-based web UI

  • Served via Nginx

• Backend Microservices (Logic Layer):

  • Node.js (Express) – e.g., Cart service

  • Java (Spring Boot) – e.g., Orders service

  • Python (Flask) – e.g., User service

  • Go – e.g., Shipping service

  • PHP – e.g., Payment service

  • Services communicate internally using REST APIs or messaging

• Data Layer:

  • MongoDB – NoSQL DB for product/user info

  • MySQL – Relational DB

  • Redis – In-memory cache/store for session/cart data

  • RabbitMQ – Message broker for asynchronous communication between services

🏗️ Architecture Highlights

• Microservices architecture enables independent scaling, development, and deployment.

• Each service runs in EKS as a Deployment or StatefulSet, exposed via Kubernetes Services.

• Databases are backed by EBS volumes for persistence.

• Ingress is managed by the AWS Load Balancer Controller using an Application Load Balancer (ALB).

• This represents a realistic, resilient, and scalable three-tier cloud architecture deployed entirely on AWS using infrastructure as code and Helm charts.

Prerequisite- Configure AWS CLI, install Kubectl and eksctl and helm in ubuntu ec2 machine.

1. Create an EKS Cluster with eksctl

eksctl create cluster --name demo-cluster-three-tier --region us-east-1

2. Enable IAM OIDC Provider for the Cluster

export cluster_name="demo-cluster-three-tier"
# Get the OIDC issuer ID for the cluster
oidc_id=$(aws eks describe-cluster --name $cluster_name --query "cluster.identity.oidc.issuer" --output text | cut -d '/' -f5)
# Check if OIDC provider is already associated
aws iam list-open-id-connect-providers | grep "$oidc_id" || echo "OIDC provider not found"

eksctl utils associate-iam-oidc-provider --cluster "$cluster_name" --region us-east-1 --approve

This command sets up the IAM OIDC (OpenID Connect) provider for your Amazon EKS cluster. By enabling OIDC, you allow Kubernetes service accounts to be associated with IAM roles using annotations. This is a critical step for enabling fine-grained permissions for specific pods.

With OIDC in place, IAM roles can be assumed by pods via service accounts — a requirement for deploying components like:

• AWS Load Balancer Controller (to manage ALBs/target groups)

• EBS CSI Driver (to dynamically provision persistent volumes)

In essence, this integration ensures your workloads in Kubernetes can securely access AWS resources using IAM roles without embedding credentials in pods.

3 Enable the EBS CSI Driver (Persistent Storage)

Our application includes stateful services (MongoDB, MySQL, Redis), which require persistent storage in Kubernetes. AWS EKS supports the EBS CSI Driver to provision Amazon EBS volumes for Kubernetes PersistentVolumeClaims. We need to install this driver (as an EKS add-on) so that our database pods can have durable storage. Before installing, we must create an IAM role for the CSI driver.

a. Create IAM Role for EBS CSI: We will create an IAM role that grants permissions for EBS volume operations, and associate it with the EBS CSI driver’s service account:

eksctl create iamserviceaccount --name ebs-csi-controller-sa --namespace kube-system --cluster $cluster_name \
  --role-name "AmazonEKS_EBS_CSI_DriverRole" --role-only \
  --attach-policy-arn arn:aws:iam::aws:policy/service-role/AmazonEBSCSIDriverPolicy \
  --region us-east-1 --approve

This command creates an IAM role named AmazonEKS_EBS_CSI_DriverRole with the Amazon-managed policy AmazonEBSCSIDriverPolicy attached (which allows Kubernetes to manage EBS volumes). We used --role-only because EKS Add-ons will create the service account for us; we just need the role ready.

b. Install the EBS CSI Driver Add-on: Now enable the EBS CSI driver for your cluster:

eksctl create addon --name aws-ebs-csi-driver --cluster $cluster_name \
  --service-account-role-arn arn:aws:iam::<YOUR_AWS_ACCOUNT_ID>:role/AmazonEKS_EBS_CSI_DriverRole --region us-east-1 --force

This command tells EKS to install the official aws-ebs-csi-driver add-on in the cluster, using the IAM role we just created for its service account. After a short time, the EBS CSI driver pods will be running in kube-system namespace (you can check with kubectl get pods -n kube-system -l app=ebs-csi-controller). Once this is complete, your cluster can dynamically provision EBS volumes for any PersistentVolumeClaims that our application’s StatefulSets might create. In summary, the cluster is now configured with everything needed: an OIDC provider, the ALB ingress controller, and the EBS CSI driver – fully ready to host our microservices application.

4 Deploying the Microservices with Helm

With the infrastructure in place, we can deploy the Robot Shop application onto the EKS cluster using Helm. The GitHub repository we cloned contains a pre-built Helm chart that defines all the Kubernetes objects (Deployments, Services, StatefulSets, etc.) for the 3-tier app. We will use that chart to install the whole stack in one go.

1. Clone the Repository (if not already done)

git clone https://github.com/sushma777/three-tier-architecture-demo.git

cd three-tier-architecture-demo/EKS/helm

This repository contains the code and manifests for the Robot Shop application. In particular, the EKS/helm directory contains a Chart.yaml, templates, and an ingress.yaml file – everything needed to deploy on EKS with one Helm command. (If you already cloned the repo earlier for local testing, just navigate to EKS/helm.)

Note: The Helm chart is configured to use pre-built Docker images for all services (hosted on Docker Hub), so you do not need to build or push any images manually. The default values should work out-of-the-box for a demo deployment.

2. Install the Helm Chart on EKS

We’ll deploy all components into a dedicated Kubernetes namespace (for cleanliness). Create the namespace and install the Helm release:

kubectl create namespace robot-shop
helm install robot-shop . -n robot-shop

This tells Helm to install the chart in the current directory (.) into the robot-shop namespace, with the release name robot-shop. Helm will then create all the necessary objects: deployments for each microservice, stateful sets for database components, services for internal communication, etc. After running the above commands, Helm’s output should indicate it created a number of Kubernetes resources. Indeed, this single step provisions “all the services, deployments, and configurations necessary for the Robot Shop application to run inside your EKS cluster.

kubectl get pods -n robot-shop

All pods should eventually show as Running (or Completed for any one-time jobs). If any pods are in CrashLoopBackOff, you may need to check logs, but in a normal scenario they should start correctly since we’re using known-good images.

3. Configure Ingress and Load Balancer (Expose the Application)

At this point, the application is running internally in the cluster, but we need to make it accessible from the outside. To do that, we’ll create a Kubernetes Ingress resource which the AWS ALB Controller will pick up and create an external Application Load Balancer for. The Helm chart directory provides an ingress.yaml file with the necessary Ingress configuration (it likely defines path routing to the web service, which is the frontend).

Apply the ingress manifest: kubectl apply -f ingress.yaml

This creates an Ingress resource (in the robot-shop namespace) that maps incoming HTTP requests to the web service of our application. The AWS Load Balancer Controller we installed will notice this and immediately start provisioning an ALB to satisfy the Ingress. Within a few minutes, a new ALB will be created in your AWS account (you can check the EC2 > Load Balancers section in the AWS console to watch its progress). The Ingress controller will also create a corresponding Kubernetes Service of type LoadBalancer under the hood, but you primarily interact with the Ingress itself.

It may take 5-10 minutes for the Application Load Balancer to be fully provisioned and in an “active” state. You can verify that the Ingress has been assigned an address by running:

Deploy the ALB Controller via Helm

helm repo add eks https://aws.github.io/eks-charts
helm repo update

eksctl create iamserviceaccount --cluster=demo-cluster-three-tier --namespace=kube-system   --name=aws-load-balancer-controller   --role-name AmazonEKSLoadBalancerControllerRole   --attach-policy-arn=arn:aws:iam::450221254409:policy/AWSLoadBalancerControllerIAMPolicy  --region us-east-1  --approve 
helm install aws-load-balancer-controller eks/aws-load-balancer-controller -n kube-system \
  --set clusterName=$cluster_name \
  --set serviceAccount.create=false \
  --set serviceAccount.name=aws-load-balancer-controller \
  --set region=us-east-1 \
  --set vpcId=<YOUR_VPC_ID>

Once the STATUS shows an address (which will be an AWS ALB DNS name), your application is available on that URL. For example, you might see an address like k8s-robotsho-robotsho-c4f0ee37ee-504582236.us-east-1.elb.amazonaws.com. You can also get the ALB’s DNS by checking the AWS console.

4. Access the Application

When the ALB is ready, copy its DNS name and try opening it in your web browser (it will be serving on HTTP port 80 by default). You should see the Robot Shop storefront load in your browser, confirming that the frontend service is reachable. From there, you can navigate the site: create a user account, browse products, add items to your cart, and perform a checkout. These actions will trigger the various microservices (user, catalogue, cart, order, payment, etc.) to work together. If all went well, the order checkout will complete and you’ll get an order confirmation, indicating the full path through the three tiers is functioning.

At this stage, you have successfully deployed the full microservices-based three-tier application on AWS EKS. The ALB is handling external traffic and routing through the Ingress to the web frontend, which in turn calls internal services. Kubernetes is managing the scaling and networking of all those components behind the scenes.

Tip: You can also verify all Services are properly exposed by running kubectl get svc -n robot-shop. Most services are ClusterIP (internal only), but the ingress/ALB provides the external access point. If you described the Ingress (kubectl describe ingress -n robot-shop), you would see annotations that the ALB controller added (like AWS load balancer ARNs, etc.), and the rules mapping /* path to the web service.

5.Clean Up Resources

If you are done experimenting, remember to delete the AWS resources to avoid ongoing charges. The easiest way is to delete the EKS cluster, which will also delete node instances and load balancers:

eksctl delete cluster --name demo-cluster-three-tier --region us-east-1