We use EKS in our company to run containerized applications. I work in the container ecosystem team, and we manage EKS clusters for our developer teams so they don't have to. We provide them with the necessary tools to run on top of the cluster.
EKS helps us simplify and speed up cluster management. We don't have to take care of cluster updates; we just initiate the update, and AWS handles it. The same goes for some of the AWS-managed add-ons.
The biggest improvement is that we now have more time. When we shifted the responsibility of cluster management and updates to AWS, we had more time to develop solutions that make life easier for the developers.
Application deployment is more automatic. They don't have to issue cluster commands; they can simply do a commit into our internal GitHub Enterprise, and our tooling will deploy or update the application on the cluster. That's probably the biggest benefit because we had time to develop such solutions.
From my personal perspective, I think it's good that we can use AWS CLI to manage the cluster, and that way, we can automate the work via scripts. Of course, the way that we just issue a command and AWS handles the work, like with cluster updates, is also valuable. That's probably one of the reasons why we use it.
Sometimes I have trouble because, in our corporate network, there are various networks, etcetera. It's difficult to connect to some of the clusters, and it's easier to go through the UI when troubleshooting something. At some points, the UI seems limited to me with the functions it provides.
You can get information like what kind of port is running on the cluster, but I haven't really explored the UI so far, so it's difficult for me to see the logs, for example. Or sometimes, you are only limited to the basic Kubernetes things.
We have certain customizations installed in the cluster, and for that, you really have to use kubectl from the command line. You are not able to use the EKS UI to list certain custom resources. So maybe there can be some kind of improvement, but maybe it's just me that I haven't really explored the UI that much.
I have been using it since February.
I don't really remember any issue with EKS, the product from AWS as is. There can be some issues when there is a bigger outage on the AWS side; it's either some kind of network outage when we cannot reach AWS itself or something similar, but I wouldn't blame EKS for it.
When we had problems with the cluster itself, I think it was more about some issue that either we as a team introduced by human error, from some configuration mistake, or our customers sometimes made mistakes. And maybe there are issues when the application running on top of EKS somehow gets into some loop or something and then doesn't work correctly, but I wouldn't really attribute that to EKS.
Because I've been in the team for a short amount of time, I don't really remember any big issue that was caused by EKS itself in the past six months at least.
It is scalable. We use the cluster autoscaler tool that spins up a new node when we need more, and that works nicely. So I think from the scalability point of view, it's okay.
In the last six months, I don't really see any issue with scalability. We run around one hundred clusters. Some of them are quite small, really just the basics where we are running free master nodes in the free availability zones, just to make things according to best practices. So, really a minimal cluster.
And there are also some really big clusters with over a hundred worker nodes. Overall, I think it's quite big. And with EKS, we are able to manage it quite well.
I have some experience with AWS support, and it was good. We were trying to solve something with one of the add-ons, and I think we solved it within a couple of days. We even had a call with one of the support engineers. So I think it worked out well.
The issue was regarding one of the AWS-managed add-ons. I remember that we clearly had some kind of misunderstanding between us and technical support, and it seemed like either we were not able to explain it correctly or the guy wasn't able to understand us. But I remember that somehow we solved that issue. So at the end, it was okay.
Neutral
The deployment process of EKS was done before I joined the team.
For me, EKS UI is nice, and it was quite easy for me to get familiar with. I find the AWS CLI quite nice to use as well. I've been working in IT for some time now, so I have some level of experience. I guess these things come sort of naturally to me now, such as how to use the tools that are provided by companies. It's usually no issue for me.
From the maintenance point of view, I don't know much about how things are backed up, etcetera. I think that is exactly why we use EKS because we don't really have to take care of cluster backups. We can simply issue a command, and the cluster will update. If we were to do cluster updates manually, it would be more work. We would have to update the worker nodes and then update the master node one by one. AWS now handles all of this. So I think from the maintenance point of view, it's great, and that's why we use it because it's now much more simple and faster for us.
We still see the benefits of using this solution because we are using it. And we actually plan to transfer all our workloads to EKS if things were ideal. But for some legal reasons, we still have to manage some on-premise clusters, but I think the benefits are there.
If you have the money, I would recommend the EKS product to other users who are looking into implementing it. It's a good tool. It really takes some of the management burden off your back.
Overall, I would rate it an eight out of ten.
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.
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.
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.
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.
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.
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.
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.
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.
We shifted from EKS to GKE (Google Kubernetes Engine). We are saving around 20% with that change.
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.
I used Amazon EKS for my personal learning purposes. I used the solution to learn how to initiate and upgrade the Kubernetes cluster for testing in my own lab.
Amazon EKS is a good tool for my testing and learning purposes. The solution's performance is good. It is a good solution for my learning and my labs.
The solution's graphical interface is not the best. It could be better in terms of enabling some integrations or managing the configuration.
I have been using Amazon EKS for one or two years.
I rate the solution’s stability ten out of ten.
Amazon EKS is good when it comes to scaling the cluster, adding, removing, or upgrading the nodes. Upgrading the machine's resources is easy.
Amazon EKS has a big community, and support is really good.
The solution's initial setup was easy.
If the deployment fails, you're still up and running. Scaling up or down can be done with zero downtime.
Some of the Kubernetes clusters were on Amazon, GCP, and Azure. I used most of them on-premises. I installed the Kubernetes cluster in my own environment.
Overall, I rate the solution ten out of ten.
The use case for Amazon EKS is for a payment gateway corporation whose applications run on microservices. Their software team develops cloud-native applications. They use Amazon's public cloud for these applications but find it expensive. They want a less expensive solution for their customers.
We suggest using Amazon EKS open-source solutions. By using these solutions on-premises, they don't have to pay Amazon.
Amazon EKS is a useful solution for modern, cloud-native applications. It offers both horizontal and vertical scaling, which is a big advantage. The tool can also help manage costs while maintaining high availability.
Integrating Amazon EKS with other AWS services is easy if you know how to connect your applications and understand programming. It depends on how your application uses modern programming languages.
The main thing to improve with Amazon EKS is the price. However, these services can be very expensive. For example, in countries like Turkey, the cost is too high. That's why we offer our cloud solutions locally. We developed hybrid solutions, but their prices are still very high.
I rate the tool's stability a nine out of ten.
The solution is very scalable. We have two customers for Amazon EKS.
We don't use support. Our customers use it.
The tool's deployment is easy. The deployment process is very simple. First, create an account. It's very organic. After that, choose the service that will be used for the project and create new services. Provide your credentials to connect to the environment. If you want to use a private link, you'll need to use a private connection.
I rate the overall product a nine out of ten. If you want to start quickly and have time constraints, you can use Amazon solutions because no time or effort is needed to prepare your environment for the market, and no hardware or infrastructure requirements are required.
It can affect team productivity with a few customers. Productivity depends on the customers' knowledge. If their developers or software team are familiar with using hyperscale issues, it is very productive to use it.
If you need off-site backup solutions, object storage, or to check your data's secondary version for disaster recovery, you can use AWS Backup or Amazon EKS service, like S3 buckets. It's very useful.
We use Amazon EKS to manage containerization within our microservices environment.
The product's most valuable features are scalability, observability, and performance.
They could add logging features. At present, we use external tools to increase and decrease the number of instances.
We have been using Amazon EKS for three years.
It is a stable service. We never encountered system downtime.
In organizational environments, especially when utilizing the console, EKS is the primary choice. Out of ten clients, approximately eight opt for EKS due to its scalability and robust features.
We contacted AWS support for EKS when we encountered difficulties connecting to private subnets. The support team guided us through the necessary steps to address these issues.
Scalability and security considerations drove the decision to migrate to EKS from another product.
The initial setup was straightforward, especially when Terraform was utilized to generate the setup. We must make minor adjustments, such as changing the name and configuring VPN settings. Overall, it's a relatively easy task for me.
The platform is worth the investment.
The product pricing depends on the specific requirements. For instance, clients between $3000-$4000 per month might find the pricing reasonable, with clusters priced around $70 to $80 plus additional costs. However, the actual pricing can vary based on the number of services utilized.
With numerous tools and plugins available for EKS like Graphite and Prometheus, users can effectively manage logs and monitor performance.
For beginners, it's essential to grasp the fundamentals of Docker and containerization and understand how containers operate. Once these basics are clear, the next step is to familiarize oneself with Kubernetes and container orchestration concepts.
I rate it a nine out of ten.
I use the solution for its microservices. I used the product in some of my personal projects for deploying applications. From an organizational standpoint, the product is useful for its microservices.
When it comes to Amazon EKS, there are IAM permissions and RBAC. When you create an IAM user, you give the privileges on the cluster level, but there won't be anything inside the clusters. In the clusters and their respective files, you will have to map the IAM user created with the help of AWS. The documentation part of the product is an area of concern that needs to be made easier from an improvement perspective.
I have experience with the tool for the past six to eight months. For some of my personal projects, I have been using the product for a year and a half. I am a customer of the product.
Stability-wise, I rate the solution a ten out of ten.
Scalability-wise, I rate the solution a ten out of ten.
The product's initial setup phase is easy since it is only based on a one-line command to help you set up an EKS cluster.
The product is available at such a huge scale in the market since the resources that are offered under the tool are competitively priced and available at a much cheaper rate compared to other solutions.
One of the aspects of Kubecost and Amazon EKS is that you don't have to manage the master node. The scalability and connectivity between API servers and its resources, including its scheduler and controller, are all taken care of by AWS. Not being easily able to log in to your master node makes things secure.
I found the cluster autoscaler of AWS to be very helpful. It is easier for users since the cluster autoscaler takes care of the nodes, making everything easy for me. With the cluster autoscaler, all the resources are presented to me, so I need not consider any integrations from the outside environment. The aforementioned reasons made it easy for me to set up the software and scale down the resources easily.
I recommend the product to those who plan to use it. Kubernetes is a product from Google, which offers good compatibility. Kubernetes and its compatibility with Amazon is decent enough for users, in my opinion.
I rate the overall tool a ten out of ten.
Amazon EKS can be used to implement and create clusters. It is also used to deploy and secure the already configured applications. EKS is a cloud-based container management service that integrates with Kubernetes to deploy applications. It automatically manages and scales clusters of infrastructure resources on AWS with Kubernetes.
EKS eliminates the need to install, operate, or maintain a Kubernetes control plane on AWS. Amazon handles everything. We just need to know how we can make it more secure, and we can use it to deploy your applications. It scales automatically, making it one of the best services.
Assigning roles and responsibilities to interact with a created cluster as a user over a command prompt is cumbersome on AWS. Initially, we create a user to interact with a cluster. Since everyone can't use the cluster, we need to assign some permissions to that specific user. It is very cumbersome to assign permissions to users to interact with a cluster. We always get errors, and it takes many days to resolve that permission issue before the user can start interacting with the cluster.
I have been using Amazon EKS for eight years.
Amazon EKS is a stable solution.
Amazon EKS is a scalable solution.
The solution’s technical support is good.
The solution’s initial setup is easy, but assigning permissions to users is difficult.
Amazon EKS is not a cheap solution.
Google Cloud Platform has a service similar to EKS called GKE. It's very easy to implement permissions in GKE as compared to EKS.
Overall, I rate Amazon EKS a seven out of ten.
The solution is easy-to-set up. It is quick, and the main management is conveniently maintained in AWS, eliminating concerns.
I'd like improved traffic handling and additional application details within the system.
I have been working with the solution for three years now.
Amazon EKS is stable.
The solution is scalable.
The solution is straightforward to set up.
We are also working with VMware Tanzu.
I would recommend the solution. Overall, I rate it a nine out of ten.
We use Amazon EKS as an APM tool for the environment while migrating the monolithic architecture to microservices architecture. It helps us to test product functionality in a particular environment.
We don’t have to manage a bunch of infrastructure. Additionally, enabling auto-scaling for both outgoing and node work helps us optimize the cost. It has valuable monitoring and insights features as well.
The product’s pricing needs improvement.
We have been using Amazon EKS for more than three years.
It is a stable product.
We have 200 Amazon EKS users in our organization. It is a scalable product.
The initial setup process takes a few minutes to complete. It requires a team of seven executives to work on the deployment.
The product generates a return on investment with the help of OpEx and CaPEx licensing models.
Amazon EKS is expensive.
I rate Amazon EKS a nine out of ten.
The solution can be described as a microservice, and it is also a fully containerized platform. The solution can be described as a stateless service. Amazon EKS can be a great solution for deployments since it supports autoscaling and keeps scaling as well. In my company, we only pay for the resources we use, and owing to such a concept, we use the solution in our company.
The most valuable feature of the solution stems from the fact that it allows developers to shift applications. The value of the solution is good when compared to tools deployed on an on-premises model.
If you compare Amazon EKS with OpenShift, the latter provides users with a solution that is fully managed through automation. Amazon EKS is not a solution that can be fully managed through automation, making it an area of concern where improvement is required. Amazon EKS should be manageable through a web portal or web interface, a feature that exists in OpenShift.
Amazon EKS should be available as a fully managed service since we use Helm chart to deploy the product in our company right now.
The initial setup phase of the product is an area where certain improvements can be made.
As a consultant, I use Amazon EKS, depending on the project requirements of my company. I have used Amazon EKS within the past twelve months. I am a customer of Amazon.
The stability of the solution is good. I can't comment much on the stability part of the solution since there is a different team in my company that takes care of the maintenance part of the solution.
I won't be able to comment on the scalability of the solution. I haven't had any reasons to deal with the product's scalability options.
I did not meet with any issues when trying to connect with the solution's technical support. At times, there may be some delays in response from the technical support team. I rate the technical support a seven out of ten.
Neutral
In the past, I was using another solution. I switched to Amazon from a different solution. Amazon's support is good. Amazon also provides a number of managed services.
I rate the initial setup phase of the product a six on a scale of one to ten, where one is difficult, and ten is easy.
The initial setup phase of the product was a bit difficult.
The solution is deployed on Jenkins and CI/CD.
The product's initial setup phase was taken care of by one of our company's in-house teams.
I rate the overall product a seven out of ten.
