Project Overview
HolidayTribe is a travel-tech business that runs its customer-facing website and product services on AWS across dev, production, and staging environments. Like many fast-growing platforms, HolidayTribe built its systems piece by piece on Amazon EC2. While this approach worked, it was not a well-designed system.
Cloud Solitaire Technologies was brought in to lead full AWS platform engineering, redesigning the architecture and migrating the platform from EC2 to Amazon EKS with zero downtime and no single points of failure.
This case study covers the six engineering workstreams we ran in parallel, and the measurable outcomes for reliability, observability, cost, and delivery speed.
Challenges
As HolidayTribe’s traffic grew, the cracks in its EC2-based infrastructure were growing. The platform had several structural problems, commonly found in companies that scale faster than their infrastructure practices:
- No centralized logging or monitoring across services
- No autoscaling or self-healing under load
- No high availability and multiple single points of failure
- High compute cost relative to actual reliability delivered
- No stored or versioned configuration
- No centralized CI/CD pipeline
These issues were not isolated. A deploy could take down a service without a rollback path. An unexpected traffic spike could disrupt the whole system. And when something did break, there was no dashboard, alert, or log trail to explain why. This describes a platform that developed naturally using basic EC2 instances, without a clear plan for managing infrastructure or using container systems - and that creates technical issues a move from EC2 to Kubernetes can help fix.
Our Approach
A successful EC2 to EKS migration is more than just containerizing and moving the app. Delivery, infrastructure, observability, reliability, cost, and scale all have to be addressed together, not one at a time. Otherwise, you just end up with a containerized version of the same fragile system.
We divided the work into six parallel areas, each managed independently while supporting the others: CI/CD & Delivery, Infrastructure as Code, Observability & Monitoring, Reliability Engineering, Cost Optimization, and Autoscaling & High Availability.
Solutions
CI/CD & Delivery
We set up Jenkins as the central delivery system, with automated, version-controlled pipelines. Auto-scaling build agents handle demand, while separate setups support Node, Java, and Python. Slack alerts provide instant updates on build success or failure.
Infrastructure as Code
Dev, staging, and production are provisioned using the same modular Terraform codebase, preventing
configuration drift. All infrastructure changes are version-controlled and auditable. Terraform can
also reconcile any drift with a single terraform apply, with Jenkins, OpenSearch, and core AWS
components like VPC, ECR, and EKS managed from one place.
Observability & Monitoring
Implementation of Prometheus and Grafana for real-time platform health with golden-signal dashboards covering latency, errors, and saturation, plus severity-based alerting. Built a Kafka-buffered pipeline on the logging side, and ALB access logs are pulled into OpenSearch for full request-level visibility.
Reliability Engineering
We fixed the timing gaps between Kubernetes and the load balancer with pod readiness gates, tuned deregistration delay so draining connections finish cleanly, pre-stop hooks that let in-flight requests complete before SIGTERM, and Pod Disruption Budgets that cap how many pods can go down at once.
Cost Optimization
We applied three cost levers: spot instances with graceful draining, a Savings Plan for predictable steady-state compute, and off-hours scale-down for non-production environments. Steady-state costs came down without affecting availability.
Autoscaling & High Availability
Every service now runs on Amazon EKS with full high availability. For tracking real demand, Horizontal Pod Autoscaling scales pods on CPU, memory, and custom metrics. Karpenter automatically scales nodes as needed, eliminating manual capacity planning. Workloads run across Availability Zones, so losing one zone won’t bring down the platform.
Technologies & Tools Used
| Area | Tools |
|---|---|
| Container orchestration | Amazon EKS, Karpenter |
| Infrastructure as code | Terraform |
| Deployment & packaging | Helm, declarative Jenkinsfiles |
| CI/CD | Jenkins |
| Monitoring | Prometheus, Grafana |
| Logging | Fluent Bit, Kafka, OpenSearch |
| Load testing | k6 |
| Cost optimization | Spot Instances, AWS Savings Plans |
| Core AWS building blocks | VPC, ECR, Application Load Balancer, SQS |
Results
- Reliability: deployments no longer drop traffic, and repeated 5xx/503 errors are eliminated.
- Observability: from losing logs silently to preventing drops, with a dead-letter queue that makes every failure visible.
- Cost: cloud spend reduced through Spot, a Savings Plan, and off-hours scale-down.
- Delivery: all services migrated from EC2 onto EKS with autoscaling and self-healing, under templated, self-service CI/CD.
Key Takeaways
A successful migration from EC2 to EKS requires parallel execution involving delivery, infrastructure, observability, reliability, cost, and scalability, all moving together instead of in sequence.
Random 5xx errors during deployment are not capacity issues; they are timing mismatches between the Kubernetes pod lifecycle and load balancer registration. They are fixable with deregistration delay tuning, readiness gates, and Pod Disruption Budgets.
Cost optimization - Spot, Savings Plans, and off-hours scaling - is handled separately from the migration, so costs come down without compromising reliability.
The same business, the same AWS account, rebuilt so that growth incidents and deployments stop being events the team has to survive. HolidayTribe’s platform now scales itself, heals itself, and no longer loses a request.
Frequently Asked Questions
What does migrating from EC2 to EKS actually involve? Containerizing existing services, redesigning deployment pipelines around Kubernetes primitives, rebuilding infrastructure as reusable Terraform modules, and layering in observability and cost controls.
Can you achieve zero-downtime deployments on Kubernetes? Yes. Zero-downtime rollouts on EKS need correctly configured pod readiness gates, tuned load balancer deregistration delays, pre-stop hooks, and a Pod Disruption Budget. All of these address the timing gap between Kubernetes and the load balancer that causes most deployment-related 5xx errors.
Does moving to Kubernetes reduce AWS costs? It can, when combined with Spot instances for interruption-tolerant workloads, Savings Plans for steady-state compute, and off-hours scale-down for non-production environments. But cost optimization is a separate workstream from the migration itself, not an automatic side effect of it.