CloudMartAWS EKS Microservices Platform
- Period
- May 2026 - Jun 2026
- Project type
- University Group Project
- Role
- Infrastructure & Deployment Lead (4-Person Team)
- Team
- 4-person team
A five-service e-commerce platform deployed to Amazon EKS with Terraform, managed AWS data services, workload identity, network isolation, observability, CI/CD, FinOps, and recovery runbooks.
- Separately deployable workloads
- 5ServicesSeparately deployable workloads
- Three-tier VPC
- 2Availability zonesThree-tier VPC
Overview
CloudMart turns a compact shopping application into an auditable cloud platform. Five independently deployable services run locally with in-memory adapters and switch to DynamoDB, RDS PostgreSQL, SQS, SES, and CloudWatch in AWS without changing route logic. The infrastructure includes a two-AZ, three-tier VPC, ARM64 EKS nodes, workload identity, network policy, health gates, scaling, cost controls, and disaster-recovery procedures.
Role & context
- Role
- Infrastructure & Deployment Lead
- Team
- 4-person team
- Type
- University Group Project
- Period
- May 2026 - Jun 2026
Built by a four-person team for the University of Moratuwa IS 4630 Cloud Infrastructure Management assignment. I led networking, VPC design, infrastructure as code, and deployment, owning the Terraform root plus networking and EKS compute modules while integrating cross-cutting platform blockers with the team's container, security, CI/CD, observability, FinOps, and recovery work.
Problem
The assignment required more than hosting an application: the team had to separate service responsibilities, preserve a simple local workflow, deploy safely on managed Kubernetes, remove static credentials, and produce operational evidence for security, observability, cost governance, and recovery.
Approach & architecture
A Kubernetes-hosted service layer uses managed AWS data and messaging services inside Terraform-provisioned network and identity boundaries.
Practices followed
Reusable Terraform modules for a multi-AZ network, EKS compute, remote state, and environment sizing
Per-service workload identity and managed secrets instead of static application credentials
Health probes, resource limits, rolling updates, horizontal scaling, disruption budgets, and default-deny network policy
Immutable ARM64 container images with OIDC-based CI and supply-chain security checks
Documented observability, cost budgets, architecture decisions, recovery objectives, and demonstration fallbacks
Challenges & resolutions
Several AWS and Kubernetes resources disagreed on ingress, service-account, secret, and token-audience contracts.
FixAligned the ALB ingress class, IRSA service accounts, RDS-managed secret access, CSI token audience, and Terraform dependencies across modules.
The target EKS node group used ARM64 while CI runners built on x86 infrastructure.
FixAdded QEMU and Buildx to produce architecture-correct, immutable container images in CI.
Outcomes
Delivered a coherent 5-service application with local adapters and AWS-managed production adapters
Provisioned a 2-AZ, three-tier AWS network and managed ARM64 Kubernetes cluster with reusable Terraform modules
Implemented workload identity, secrets integration, network policy, scaling, disruption budgets, and health gates
Demonstrated the browser-to-services-to-managed-data-to-queue-to-email flow during the dated live audit
Tech stack
Concepts & skills8
- AWS network architecture
- Amazon EKS operations
- Terraform module design
- Kubernetes workload identity
- ARM64 container delivery
- NetworkPolicy and least privilege
- Cloud observability and FinOps
- Disaster recovery planning