Amazon EKS Reviews

The main use case is Cloud and IT applications.

It's a faster solution to adopt on native applications.

I would like to see a cloud setup bank management feature.

I have been using Amazon EKS for six years.

I would rate the product's stability a nine out of ten.

I would rate the tool's scalability a nine out of ten.

There is a return on investment.

Before EKS, we evaluated AKS and CKS.

Review the organization's strategy with your strategy, whether it is oriented to the portability of your applications. Overall, I would rate Amazon EKS a nine out of ten.

We deploy different solutions on the EKS cluster for our clients to use.

Since it is a managed service of AWS, Amazon EKS helps us in the managing and autoscaling of services. We don't have to worry about multiple things like managing the nodes or IP addresses and can focus on our work.

Through Amazon EKS, we can have the blue-green deployment very easily.

The management of the nodes in Amazon EKS should be improved. AWS should reduce the constant upgrades of the nodes of Amazon EKS or EC2 machines.

I have been using Amazon EKS for almost two years.

I rate Amazon EKS a seven out of ten for stability.

I rate Amazon EKS a nine out of ten for scalability.

The solution's technical support is very good.

Positive

The solution's initial setup is straightforward for us because we use Terraform scripts, which we have written and can reuse. It is the same for the console.

If your application goes to production, you will definitely see an ROI with Amazon EKS.

The solution's pricing is fair enough and a little less costly.

I would recommend Amazon EKS to other users.

Overall, I rate Amazon EKS an eight out of ten.

Our client is doing some image analysis, and we need a robust system that won't go down during the image rotation, so we are using Amazon EKS. With this solution, our services will not go down during their work, and data will remain safe and available to the user.

Firstly, whenever a service goes down, EKS automatically makes up that part, enabling the services to remain available. And secondly, whenever we deploy anything, we don't have to consider security between services because EKS provides that as well. We need to configure some supportive plug-ins and tools, which is relatively easy. This feature also provides monitoring, so if our service goes down, we have an alert mechanism and logging.

We can deploy EKS microservices on any service we are developing.

The solution could be improved by adding monitoring, filtering, and logging capabilities to its current CloudWatch features.

We've been using the solution for one and a half years.

We haven't faced any major issues in one and a half years of use. We had an issue with storage, which we capped, giving us access to more space from the cloud. There are some other minor issues, but nothing major.

I would rate the solution's stability as eight out of 10.

We use the solution because it allows you to scale your application up and down. 

We have 500 data scientists actively using our EKS tool at any time.

We usually get support on time, but sometimes we have critical issues or something they need more time to deal with. 

We would give them nine out of 10 for the quality of support.

The initial setup is straightforward.

When deploying the solution, we used Jenkins to develop a CI/CD pipeline. It was a one-person job that took about 20 to 25 minutes.

On a scale of one to 10, we would give the product an overall rating of eight.

EKS is for deploying microservice projects. If you have multiple services in your application, you can deploy them and design your application accordingly.

We can deploy EKS microservices on any service we are developing.

I would certainly recommend the product to new users, but it would depend on the technology stack and the project. If a certain use case requires EKS, I would definitely advise using EKS rather than Google or Azure's EKS. I recommend Amazon Cloud Services for its reliable support and minimum downtime. 

Our client in the healthcare industry has multiple clinics and patients who use the solution to interact with their portal and insert patient details. Patient information is managed via databases created in the solution. 

We are still exploring how the solution benefits us because we are enhancing many things on the application side including bug fixes or other items at the code level. 

On the cluster side, we are exploring options to enhance application performance. We are not sure if the solution has created a drastic change, but before we were able to perform and now we are performing well. 

The solution's Autoscaler option allows for an increase in worker notes whenever particular thresholds are exceeded. In our client's case, this is beneficial because the application sits idle the whole night and peaks in the morning hours of 9-10 am as everyone starts interacting with it and processing their workload. 

The solution is quite intelligent and is enhanced every day. They recently introduced a carpenter service that provides added advantages and are working on auto-scaling enhancements which have already allowed us to scale up our Kubernetes Clusters. 

The solution should include a popup for clusters so that all relevant information is visible at the bottom of a page. 

When clusters exist or are running, there isn't much detail on the first phase so navigating and clicking on different options is required to search for relevant information. 

I have been using the solution for three years. 

I really like the stability of the solution. 

We are using the solution to its full capacity to manage various environments and clusters that segregate our client's workload.

The solution is scalable and includes the ability to instruct a cluster to automatically upscale or downscale depending on thresholds written in the code. 

Support is quite good. I haven't used technical support for this solution but have raised tickets for other Amazon products such as IAM or S3 and received help with documentation and tutorials. 

I started my journey as a DevOps engineer with this solution per our client's requirement. 

I was not involved in the initial setup because all customers already had the solution in place before I started interacting with them. I know that setup requires streamlining but is quite easy and just takes time. 

I use some pipelines to deploy workloads such as Terraform or Argo CD where I build artifacts or codes that interact with the solution. Whenever a merge occurs, the pipelines get triggered and automatically deploy in the development environment. If test pieces pass, then they move to the next phase and are deployed on the production level. 

A team of five would be a good fit for a mid-level customer because they can simultaneously work on writing home scripts for the EKS Cluster, building the whole network, and reviewing existing queries. A larger company might require more developers. 

The solution is quite costly and developers will start exploring other solutions or moving their workloads to other clouds if costs aren't reduced.

Our client pays the licensing fees so I don't have specifics about its cost, but I hear that the solution is expensive so I am rating it a five out of ten. 

We are analyzing the solution's behavior but might switch to ECS which provides dedicated resources to an application and runs on its own. 

If you are interested in implementing the solution, first refer to the documentation or existing use cases. 

For example, a streaming company similar to Netflix can adopt and modify a use case related to the Amazon portal. There are resources that help with deciding to implement the solution. 

I rate the solution a nine out of ten. 

It's a great service because we can do a lot of things using it. It's easy to create clusters and services in pods there.

So, the main purpose is to create clusters and services and define some pods there.

We reduced the cost by using one cluster instead of using different services and different virtual machines in a client. So, Amazon EKS helped our organization reduce costs. 

This is the way we can create a cluster because we don't need to pay attention to the control plane. We only need to deploy the services in the worker nodes and configure some configurations, easy configurations, and the cluster is done to be published.

Basically, AWS provides all features that we have prepared.

There is room for improvement in stability. I faced some problems with the App. The problem is actually the app, with the different teams fixing it.

I have been using this solution for 18 months. I work on different projects. Basically, we create a structure and per clients, and we move to another project. So we did different projects for how long of the year.

We are currently using version 1.24, but we are migrating to the latest version, which is 1.28.70.

I would rate the stability an eight out of ten. I faced some problems with the App. The problem is actually the app with the different teams fixing it, but I would say the Kubernetes - it's ten. The service is ten. But if everything is considered, it's eight.

I would rate the scalability a ten out of ten. It is perfect. Moreover, more than one hundred users have access per hour. 

We use this solution every day. Thus, we use the solution to its maximum potential. 

We did the research for Azure, but all the structure and other resources were applied in AWS, so we kept it in the same provider.

We also used a local structure, but we're at a short time. And the infrastructure had already been done. I only need to support the application. It's full.

The thing that takes more time to be constructed with the code is minutes and hours to provide the EKS code, but with the structure is really fast.

Basically, it used the code. They used the TerraForm code because we work with ESA, and, basically, the most important part for us is the code.

We used the help of a third party, like, the partners of Amazon. 

We required four people for the deployment process. However, the maintenance depends on the number of clusters and resources. So, two people are enough for the maintenance of the solution. 

I would rate the pricing model a seven out of ten, where one is cheap and ten is very expensive.

It was rather expensive; compared to GCP and Azure, it's a little more expensive. The price can be a problem for small-sized businesses. 

There are no additional costs to the standard license. 

So I work as a DevOps engineer. But basically, using TerraForm or other tools like that, I never worked with another provider as Google and Microsoft. So, basically, I use AWS. 

Actually, there are a lot of reports that I use every day. So we use tools related to that, like load balancers, ECRs, and EKS— so different resource things.

It's a great service. Some services are more expensive compared to other providers. But in general, it's the best option for medium or large enterprises.

Overall, I would rate the solution a nine out of ten. 

Amazon EKS is used in containerization, which means that you deploy any application and package it into its own miniature server. Then, store that application in an encapsulated form within a server which is an operating system, and keep it aside so that the repository recurses.

It has always helped me. It is the repository where we store our images.

It's a cluster service. So Amazon EKS is essentially a Kubernetes service, which is a product created by Google and is open-sourced, meaning it can be downloaded and installed on a server in a company's data center without needing the cloud for containerization or microservices. With Kubernetes, you can build and deploy microservice applications within a Kubernetes cluster. So, all your microservices will be running under Kubernetes within a cluster. Kubernetes is what that particular class of software is called, and we refer to it as an orchestration tool. It'll figure out and make sure that your microservice is always available. So, you can go and tell them before starting Kubernetes about the number of properties, files, or variables and issue commands to determine the instances of microservices available, including setting a minimum of one or two instances. To shut down a microservice, you can set the instances to zero. Essentially, Kubernetes allows an organization or anyone to have a cluster of microservices served without needing a cloud. Amazon AWS offers Kubernetes as a service because they found that many people are using Kubernetes.

The microservices appear to be well-made, and I don't have any comments on them as I don't see any flaws. Essentially, each microservice has a substantial ephemeral space available, providing gigabytes of storage. It would be helpful if this default storage allocation could be reduced to avoid the need for excessive resources when running microservices.

The goal and idea behind microservices are to always be available and capable of handling any load, no matter how many requests come through. At times, there might be millions of requests from people. All of these services are great, but I also think it would be useful to have the same technology available in a miniature resource size, enabling the same applications and services to run on a small machine. Increasing resources should enable microservices to handle the demands of the world. I would like to see the technology scale up to the point where individuals can run a service from home even with fewer resources.

I have been using Amazon EKS for about four years, and there is no specific version of the tool because it automatically gets updated. So, the latest version is always available.

I personally prefer this solution to Amazon Fargate and would rate it an eight out of ten.

We use this solution for containerization and push containers into the EKS or CI/CD pipeline in the DevOps pipeline. It's very easy and well-managed for autoscale as we can manage our node groups. In addition, we can tailor autoscaling to our needs.

Amazon EKS with AWS is very good because we can connect our AWS Kubernetes Services with our CI/CD pipelines. We can integrate our EKS with our CloudWatch and Grafana, and other monitoring services are also available. We can also monitor as per our requirements.

The best solution is in AWS, in Elastic Kubernetes Services. We have general control if we want to give access to any user. Also, whenever we push a container or image, we can create any ingress and then connect to our cluster by the Load Balancer directly.

It is very easy, and we can deliver access to customers or users. Also, we can autoscale for any deployment or compute service. In addition, the control panel is completely managed by AWS, and we only have to think about a data plan and what type of deployments, services, and DaemonSets we need.

The main area of improvement is that a cluster is required on-premises, which takes a lot of time. For example, we must drain the total nodes during an upgrade from version 1.21 to version 1.22 with on-premises. After draining the total nodes, our container will shut down, and it will be recreated after upgrading. But with the AWS Kubernetes Services, the upgrade from version 1.21 to 1.22 is completed with one click. It's straightforward for the users.

In any secure services, nodes are working on the EC2 services. Whatever the EC2 services, the specified AMI is available. This AMI is an auto-security package that is automatically upgraded per the company's need. It is also secure.

We have used this solution for one year and use versions 1.15 to 1.22. It is deployed in the public cloud only, in AWS. We were initially working on an on-premises basis of Kubernetes and started working in Elastic Kubernetes in AWS. It is a managed service, and its control panel is managed in AWS. We have to work for our data plan only.

We have about 20 users pushing their container to Elastic Kubernetes Cluster. Most companies want source codes like Python, Node.js, and Java and push them to the Elastic Container Services. It makes it easy for the CI/CD pipeline to build and push images to Elastic Kubernetes Services. We recently started the containerization in Elastic Kubernetes Services.

Regarding technical support, we have the job, role, and responsibilities within our company.

If there is an issue, we must determine whether the solution is working correctly or not. We check if our node group has more or less workload than we need and if the autoscale is defined correctly. We can degrade these instances per our requirement if the node group is less. We added Grafana and Prometheus to monitor the total CPU, memory, and nodes. We can monitor requests, CPU utilization, and whether our node is behaving correctly or if we need any more memory. We also look for any issues with the HTTP request or time out.

The calculation of the pricing is dependent upon instance type. So when we make a cluster without defining any instance type, it will default enter a large instance type. So as per our requirement, we can create our node group and define our instance types per our workload.

I rate this solution a nine out of ten. Amazon EKS is the best service because it has proper security packages and manages AMI. Also, I'm working on GCP and have seen GKE services. With Amazon EKS AWS, we can do a lot of integration with our Kubernetes Cluster.

The primary use case for Amazon EKS involves microservices and micro frontends.

The most valuable features of Amazon EKS are its scalability features.

There is room for improvement in the interface of Amazon EKS. Additionally, they are involved in activities like pipeline management, pod checking, and error logging, which could suggest areas for further improvements.

I have more than three years of experience working with Amazon EKS.

I would rate the stability of Amazon EKS ten out of ten, indicating it is highly stable.

I would rate the scalability of Amazon EKS an eight out of ten, suggesting it has high scalability.

I do not have experience contacting Amazon's technical support.

I was not involved in the setup of Amazon EKS.

I would recommend Amazon EKS to other people for various reasons. That said, I also rate this solution seven to eight out of ten overall.