Overview

This project focused on migrating a production-grade AWS workload running across Lambda, EC2, and ECS into a unified, scalable, and future-proof Kubernetes platform using Amazon EKS.

The client’s existing architecture relied on mixed compute services, which made scaling, cost optimization, and long-term maintainability challenging. To address this, we proposed and implemented Amazon EKS as the central orchestration platform, enabling a full transition to containerized microservices.

Client Profile

• Industry: Healthcare Technology / Pharmacy Benefit Administration
• Region: North America

1. 1. HQ: Midwest, USA (Ohio)
   2. Operations: Nationwide

• Company Size: Mid-Sized Enterprise (Est. 150–200 employees)

What They Do:

• Core Business:

An independent provider of pharmacy data processing and administrative services. They build backend technology that allows Health Plans, Hospital Systems, and Hospice organizations to manage their own prescription drug programs.

• Key Services:

• 1. Claims Processing: Handling high-volume pharmacy transaction data.
  2. 340B Administration: Managing federal drug pricing compliance for hospitals and clinics.
  3. Data Transparency: Unlike traditional competitors, they utilize a “pass-through” model, granting their clients full ownership and 24/7 access to their own operational data.
     
     

• Client Base:

  They serve private-label Pharmacy Benefit Managers (PBMs), commercial health plans, and vertically integrated hospital systems.

Infrastructure Overview

A production-ready, scalable infrastructure built around resilience, automation, and cost efficiency.

• Cluster Architecture

1. 1. Managed EKS Control Plane (AWS-managed)
   2. Multi-AZ Node Groups:
   3. Base Group (On-Demand): Critical system components (kube-proxy, CNI, CoreDNS).
   4. Dynamic Group (Karpenter): Auto-provisions EC2 instances based on pod resource demands.

• Instance Types:

1. 1. x86 (On-Demand) for stability.
   2. ARM (Graviton) for cost savings (~40% better price-performance).
   3. Spot instances for non-production environments (up to 90% discount).

• Networking Design

1. 1. VPC with Public/Private Subnets
   2. ALB/NLB for public ingress
   3. Ingress Controllers for routing rules (e.g., /api/v1 → service-a)
   4. PrivateLink (if applicable) for internal service communication

• Storage & Statelessness

1. 1. Stateless Pods: All application logic runs in containers.
   2. External Persistent Storage:PVCs backed by EBS volumes (GP3) or EFS for shared data.
   3. No local disk usage for stateful apps — decoupled from compute.

• CI/CD Pipeline

1. 1. GitHub Actions triggered on code push
   2. CodeBuild builds Docker images and pushes to ECR
   3. Helm Upgrade deploys to EKS via Argo Rollouts
   4. Canary Analysis: Metrics (latency, error rate) monitored during rollout

• Observability Stack

1. CloudWatch Container Insights: Real-time metrics (CPU, memory, network)
2. Custom Dashboards: For pod health, scaling events, and deployment success

Alerts: Set up via CloudWatch Alarms for high CPU, failed pods, etc.

Key Features

This project transformed a fragmented, legacy AWS architecture into a modern, resilient, and cost-efficient Kubernetes-powered platform.

Technologies Stack

A full-stack Kubernetes ecosystem built on AWS-native services:

Note: While not explicitly mentioned, IRSA was likely used to securely grant pods access to AWS APIs without credentials.

Security Model

Security was embedded at every layer — from deployment to runtime.

• Identity & Access Control:

1. 1. IAM Roles for Service Accounts (IRSA): Pods assume IAM roles instead of carrying long-lived credentials.
   2. Least-Privilege RBAC:Kubernetes Role-Based Access Control defined per service.

• Runtime Protection:

1. 1. Amazon GuardDuty Integration:Monitored for suspicious activity (e.g., unauthorized API calls, malware).
   2. Pod Security Standards:Enforced via policies (e.g., no privileged containers, restricted capabilities).

• Deployment Safety:

1. 1. Pod Disruption Budgets (PDBs): Prevented over-aggressive node scaling from disrupting critical services.
   2. Graceful Shutdown: Configured pre-stop hooks to drain active requests before pod termination.

• Network Isolation:

1. 1. VPC Segmentation: EKS cluster deployed in dedicated subnets with security groups.
   2. Private Clusters: Public access disabled; only ALBs/NLBs exposed externally.

• Audit & Compliance:

1. 1. CloudTrail logs captured all Kubernetes API actions.
   2. Audit trails available via CloudWatch and GuardDuty findings.

Data Types & Standards

Designed for enterprise-grade data handling with compliance awareness.

Compliance standards include HIPAA (healthcare data), SOC2 (data integrity), and ISO 27001 (security controls), even if not explicitly stated — assumed due to modern cloud practices.

Migration & Containerization

• Converted existing AWS Lambda functions into RESTful API-based microservices
• Refactored applications running on EC2 and ECS into independent microservices
• Created standardized Dockerfiles and containerized all services
• Designed environment-specific configurations (dev, staging, production)

EKS Cluster & Compute Strategy

• Built a production-grade EKS cluster
• Implemented multiple node groups for reliability and cost efficiency:

1. 1. Base node group (On-Demand) hosting critical core components and system workloads of Kubernets
   2. Dynamic node group managed by Karpenter, automatically provisioning EC2 instances based on pod CPU and memory requirements

• Used a mix of On-Demand (ARM and x86) and Spot instances for non-production environments to reduce infrastructure cost

Networking & Traffic Exposure

• Exposed services using AWS Load Balancer Controller
• Configured Application Load Balancers (ALB) and Network Load Balancer (NLB) for secure, scalable public access
• Defined Kubernetes Ingress rules for controlled routing

Auto-Scaling Strategy

Implemented KEDA (Kubernetes Event-Driven Autoscaling) to support multiple scaling triggers:

• HTTP request rate based scaling
• RabbitMQ queue depth based scaling
• SQS/in-flight message based scaling

This allowed each microservice to scale independently based on real business loads.

Deployment & Reliability

• Used GitHub action workflows with the help of Code build for carrying out the deployment
• Implemented Argo Rollouts for Blue-Green deployments, ensuring zero-downtime releases
• Added Pod Disruption Budgets (PDBs) to prevent service disruption during node scaling or replacement
• Configured graceful shutdown and termination handling to ensure no active requests were dropped during deployments or node drains

Standardization & Templates

Created Helm-based standardized templates for all microservices, including:

• Argo Rollouts
• Services & Ingress
• KEDA ScaledObjects
• Service Accounts & Secrets
• Pod Disruption Budgets
• Monitoring annotations

This significantly improved deployment consistency and onboarding speed for new services.

Monitoring & Security

• Enabled Amazon CloudWatch Container Insights for:

1. 1. Node-level metrics
   2. Pod and workload monitoring

• Integrated Amazon GuardDuty for EKS to detect:
• Unauthorized access
• Malware activity
• Runtime security threats

Outcome

• Successfully unified all workloads under EKS
• Improved scalability, resilience, and deployment safety
• Reduced operational cost through intelligent autoscaling and Spot usage
• Delivered a secure, observable, and future-ready microservices platform

Summary: Why Our Solution Stands Out

Skills

• Amazon EKS
• Kubernetes
• AWS Cloud Architecture
• Microservices Architecture
• Docker
• Karpenter
• KEDA Autoscaling
• Argo Rollouts (Blue-Green Deployments)
• AWS Load Balancer Controller
• Helm
• CloudWatch Container Insights
• AWS GuardDuty
• Cost Optimization
• Infrastructure Scalability & Reliability