What is our primary use case?
For EKS, we deployed a Django application. The application built the whole image and stored it in ECR (Elastic Container Registry). We stored the code repository in GitHub, but the image was in ECR. We also had another repository for the Kubernetes manifest files. So we were deploying it in a different image, and the code was in a different image. We had a whole pipeline for deployment, from CodePipeline to ECR, and then from ECR to Kubernetes.
I work with different AWS solutions, such as Elastic Beanstalk, AWS Lambda, DynamoDB, and VPC. I use services like EC2, S3, and VPC every day, so I'm not including those. I've also used API Gateway, and currently, I also use AWS Bedrock.
What is most valuable?
The good thing was the integration of services. The only thing we had to think about was how we were pushing the code to GitHub or Bitbucket. After that, everything was taken care of by AWS.
Everything was connected: the code and the real-time deployment. Testing was done within the same pipeline using CodeBuild. CodeBuild was handling multiple tasks: testing the code, deploying it to ECR, and then running it on AWS Fargate for development or testing. Once it was working fine, we had an approval stage. After approval, we deployed it to EKS using the command line from the same AWS CodeBuild process.
The scalability of EKS is good. We've compared it with multiple platforms, and we've also worked with GCP. There are more good options available in GCP compared to EKS.
But the good thing about EKS is that we can use it for serverless deployments using Fargate. It gives you two options: deploy on EC2 or deploy on Fargate. EC2 runs 24/7 and costs you money, but Fargate only runs when you need it. So EKS was really helpful for saving costs with that serverless capability.
What needs improvement?
I would like to see a warm-up time for AWS Fargate, similar to what GCP Cloud Run has. This would improve internal security. I would also really love to see lower costs compared to other cloud vendors. AWS can get quite expensive.
For how long have I used the solution?
I've been working with EKS on and off for the last two years. Some of the projects were my own, and some were development projects.
Buyer's Guide
Amazon EKS
June 2025
Learn what your peers think about Amazon EKS. Get advice and tips from experienced pros sharing their opinions. Updated: June 2025.
860,592 professionals have used our research since 2012.
How are customer service and support?
They have good documentation and lots of blogs on Amazon AWS, so we mostly follow those. We haven't reached out to technical support directly. We had a plan for technical support, but it took them more time to fully help us.
Sometimes the issue is on our code side and not on AWS's side. Getting the customer service and support involved in our whole process takes a long time. It's better to research for a few hours and fix it yourself rather than waiting for a week or so.
Which solution did I use previously and why did I switch?
GKE gives you really good monitoring and logging, where you can see every bit of information flowing in your environment. AWS provides the same thing with CloudWatch, but it's much easier in GKE to see what's exactly going on. So monitoring and the transparency of what's happening would be one thing AWS needs to improve.
The pros of EKS are that it makes deployment really easy. You just need to package your image in ECR, and then everything goes very smoothly. You don't have to worry about running or managing Kubernetes. It gives you a managed control plane, and they replicate the control plane over different regions. So there's very little chance that it will go down. Reliability is really high with AWS.
How was the initial setup?
When we started we had an issue with rollbacks. We had problems because we had to specify certain AWS parameters in order to deploy it properly. We consulted the documentation and resolved it that way.
We did some testing, and that took about one month with it. Then we started with a very small infrastructure on EKS, migrating some of our traditional websites to EKS directly. So, the initial setup took about two months.
But we didn't use it for microservices; we only used it for two services: one was our platform service, and the other was Redis.
What about the implementation team?
In my case, I handled the deployment part. I had a manager, so I just took his approval and gave him the deployment design. He was overseeing everything, but I was doing almost all the AWS work. The developers were really helpful in making the code run correctly with the image versioning.
Users have to maintain things. For example, we faced an issue where we had a lot of requests coming in, and we weren't ready with enough resources at the time. We had to manually increase the Kubernetes nodes. That was an issue with horizontal scaling. It was our mistake because we didn't automate it.
What was our ROI?
We shifted from EKS to GKE (Google Kubernetes Engine). We are saving around 20% with that change.
What other advice do I have?
I already have recommended it to many people. If you're using AWS for other services, definitely go with EKS because it doesn't make sense to move to another cloud vendor if you're already using everything in AWS. The integration is really good. You get AWS WAF (Web Application Firewall) on top of it, load balancer, GuardDuty, and Inspector. So security-wise, it's really nice to have EKS surrounded by those security tools.
My advice would be to try to go with AWS Fargate initially. Try to understand how ECR (Elastic Container Registry) works because it also costs you money, so make sure your image isn't too big. And if you can, go with AWS CodeCommit, it makes things very fast. And for EKS, they can use Fargate with EKS as a service. So, users don't have to worry about scalability and reliability. It's totally managed from the user's end.
Overall, I would rate it an eight out of ten.
Disclosure: My company does not have a business relationship with this vendor other than being a customer.