i built and deployed a 3-tier app on kubernetes and aws eks

altered — Sat, 30 May 2026 15:38:06 +0000

i recently finished building and deploying a 3-tier application, starting locally on minikube and then migrating it to aws eks. this post is about what i built, how it all connects, and a couple of things that tripped me up along the way as a beginner who recently completed the aws certified cloud practitioner (clf-c02) exam and the kubernetes and cloud native associate (kcna) certification.

what i built
a simple 3-tier app with:

a frontend — nginx serving an html page
a backend — node.js api
a database — mongodb

the full picture
browser → aws alb → ingress → frontend pod (nginx) → backend pod (node.js) → database pod (mongodb) → ebs volume (persistent storage)

nothing really fancy, just needed to do some hands on in the cloud.

how it works locally (minikube)
i started on minikube, a tool that runs kubernetes on your local machine. the goal was to understand the concepts before touching any cloud resources.
each tier runs in its own kubernetes deployment, which manages your pods and keeps them running. pods talk to each other through services, which give stable dns names inside the cluster. so instead of hardcoding ip addresses, the backend just calls database-service and kubernetes figures out where that is.
sensitive config like database credentials went into a secret. non-sensitive config like the database hostname went into a configmap. both get injected into pods as environment variables at runtime.
the database needed storage that survives pod restarts, so i attached a persistentvolumeclaim. kubernetes provisions the storage and mounts it inside the database pod.
for traffic routing i set up ingress, a single entry point that routes requests based on url path. / goes to the frontend, /api/* goes to the backend.

migrating to aws eks
once everything worked locally, i deployed the same app to aws eks — amazon's managed kubernetes service. the manifests are pretty much the same except that a few things change when moving to the cloud.
for example, aws ecr(elastic container registry) replaced cases where i would have built images directly into minikube's docker daemon. on eks(elastic kubernetes service), worker nodes are ec2(elastic compute cloud) instances. so i pushed images to amazon ecr (elastic container registry) and updated my deployments to pull from there.

i used ebs(elastic block store) for database storage on aws, as opposed to that on minikube which uses local storage. i updated the storageclass in the initially deployed persistent volume claim from standard to gp2 and installed the ebs csi(container storage interface) driver so kubernetes could provision ebs volumes automatically.
locally i used minikube tunnel to expose the app. on eks, i used the alb(application load balancer). the aws load balancer controller watches the ingress resources and automatically creates a real application load balancer with a public dns address.

a couple of things that caught me out
arm64 vs amd64 — my mac uses apple silicon (arm64). when i built docker images locally and pushed to ecr, the eks nodes (which run on intel/amd processors) couldn't run them. the error showed an exec format error. the fix was rebuilding with docker buildx build --platform linux/amd64 to explicitly target the right architecture.
iam permissions — on aws, the elastic block store container storage interface driver and the load balancer controller both need to call aws apis to do their jobs. and without the right permissions attached to them, it would fail. this is solved with irsa (iam roles for service accounts) — a way to give kubernetes pods aws permissions without hardcoding credentials. you link a kubernetes service account to an iam role, and pods using that service account automatically get the right aws access.

looking to build more interesting projects on the cloud and will talk about my journey here.

DEV Community: altered

i built and deployed a 3-tier app on kubernetes and aws eks