When choosing between AWS ECS (Amazon Elastic Container Service) and Kubernetes for software development infrastructure, many teams assume Kubernetes is the inevitable destination and ECS is just a temporary compromise. But what if that's not always true?
We spoke with Mykola Ovchinnikov, a DevOps engineering expert with hands-on experience deploying containerised applications across multiple projects at StreamAMG, Kaltura and beyond.
What usually drives the decision to adopt ECS?
Over the last few years, I've worked on multiple projects where AWS ECS became a key part of our infrastructure. In most cases, the goal was not to build a "perfect" platform from day one but to ship faster, reduce operational overhead, and keep the infrastructure understandable for a small team.
One of the first ECS adoptions I worked on involved a legacy service that had been running on EC2 instances with manual deployments. Releases were slow, risky, and hard to reproduce.
We containerised the application using Docker and moved it to ECS. Configuration was externalised via environment variables, and sensitive data was migrated to AWS Secrets Manager. ECS services gave us rolling deployments out of the box, which significantly reduced downtime and made releases predictable.
This was our first real step toward container orchestration during our cloud migration, without committing to the complexity of Kubernetes too early.
So ECS was never meant to be a permanent solution in some of these projects?
In several projects, ECS was intentionally chosen as an intermediate step before Kubernetes. At an early stage, the team was small, and the product was still evolving. ECS allowed us to:
- Introduce containers and immutable deployments
- Standardise CI/CD pipelines
- Learn operational patterns (health checks, scaling, observability), without maintaining a Kubernetes control plane
After the system grew and platform requirements became more complex, the transition to Kubernetes felt much more natural. By that point, the team already understood container-based workflows, making the migration far less painful.
Did you ever choose ECS from the beginning for a brand new project?
Yes, for a greenfield project, we decided to start with ECS on Fargate to avoid managing EC2 nodes altogether. Each microservice was defined as an independent ECS Service with its own Task Definition.
This approach worked well in the early stages because services could be scaled independently, traffic routing was handled via an Application Load Balancer and infrastructure complexity remained low.
ECS allowed us to move fast while keeping the architecture clean. Kubernetes was considered, but ECS reminded us that simple is often good enough — especially at the beginning.
You mentioned ECS as a "proving ground" for Kubernetes. Can you elaborate on that?
In one project, ECS acted as a proof-of-concept platform before a planned migration to EKS.
We used ECS to validate service boundaries, container resource requirements, autoscaling behavior and logging and monitoring strategy.
Once traffic and team size increased, we migrated to Kubernetes to gain more flexibility (custom controllers, advanced networking, service mesh). Because the applications were already containerised and stateless, the migration focused mostly on infrastructure, not on rewriting services.
Beyond long-running services, did you use ECS for other workload types?
ECS was also used for background processing and scheduled jobs. Instead of maintaining dedicated worker instances or cron servers, we ran one-off ECS tasks triggered by Amazon EventBridge.
This pattern worked especially well as a lightweight alternative to Kubernetes Jobs. It allowed us to execute workloads on demand, scale to zero when idle, and keep costs under control.
How did ECS fit into your CI/CD workflows?
Across all projects, ECS fit naturally into our CI/CD pipelines. A typical flow looked like this:
- Build a Docker image
- Push it to Amazon ECR
- Register a new Task Definition revision
- Deploy it via ECS Service update
This approach provided safe, repeatable deployments with minimal custom tooling. Later, when we moved to Kubernetes, the same pipeline concepts carried over almost unchanged.
What would you tell teams trying to decide between ECS and Kubernetes?
In modern software development workflows, ECS proved to be an excellent choice when:
- The team is small or medium-sized
- Operational simplicity matters more than maximum flexibility
- Kubernetes feels like overkill at the current stage
In several cases, ECS was not the final destination—but it was the right first step. It helped us ship faster, learn container operations, and move to Kubernetes only when the project truly needed it.
Related insights
The breadth of knowledge and understanding that ELEKS has within its walls allows us to leverage that expertise to make superior deliverables for our customers. When you work with ELEKS, you are working with the top 1% of the aptitude and engineering excellence of the whole country.
Right from the start, we really liked ELEKS’ commitment and engagement. They came to us with their best people to try to understand our context, our business idea, and developed the first prototype with us. They were very professional and very customer oriented. I think, without ELEKS it probably would not have been possible to have such a successful product in such a short period of time.
ELEKS has been involved in the development of a number of our consumer-facing websites and mobile applications that allow our customers to easily track their shipments, get the information they need as well as stay in touch with us. We’ve appreciated the level of ELEKS’ expertise, responsiveness and attention to details.
