Amazon EKS Reviews

Our typical use case for Amazon EKS is that we have a number of applications and microservices that we host in EKS. We have a separate code base for the infrastructure platform, and the microservice team and the application team will be deploying their microservices on their own. We have configured it in a way that it could be easily accessible for developers as well as the platform engineers; we just platformize things. Earlier, I was using ECS, and the reason we use Amazon EKS is for better adaptation of Kubernetes, fitting our multi-tenant model.

The best features of Amazon EKS are that it is very plain by itself, but we use a number of optimizations, such as Carpenter for scaling and node auto-scaling, and Keda for application and microservices auto-scaling, as an event-based auto-scaler. Additionally, we use Portainer less, and for configuration, we utilize Cert Manager and Istio. It's not only Amazon EKS but a combination of various components within it.

By default, if you just install Amazon EKS, you can deploy your application, but to have it enterprise-ready, you have to configure a number of other things that will boost productivity.

Amazon EKS's deep integration with AWS services, such as IAM and elastic load balancing, has created some challenges. For example, we have something in place already, and there are some issues with enabling FIPS, which is FedRAMP compliant for the load balancers. You cannot change the SSL policy for the load balancer; I am not sure if it has been patched by AWS yet. However, apart from that, we use it effectively, and it is more flexible.

Regarding built-in observability in Amazon EKS, there is CloudWatch and CloudTrail. However, you cannot profile the applications; we can collect logs in S3, but there is no streaming solution available. Only CloudWatch exists, so we use other tools for observability and do not depend solely on CloudWatch, only relying on it for crucial workloads and infrastructure logs.

Amazon EKS can be improved by having the maintenance of Kubernetes versions managed better, as everything is handled by the Kubernetes team and possibly a separate team at AWS. We have to constantly maintain upgrades and ensure EKS add-ons are up-to-date, requiring us to upgrade the Kubernetes version and releases. They could provide a managed service in the backend instead of making customers handle it; we are currently doing it, but it's a regular activity we do per quarter.

I have around six years of experience with Amazon EKS.

Amazon EKS is a stable solution, as it is only available in AWS alone.

It is a scalable solution for us.

Before using Amazon EKS, I was using ECS. I switched from ECS to Amazon EKS because our product design changed. With numerous small services that you don't want to manage the backend infrastructure for, you can easily deploy and let it be with ECS; it is a more straightforward solution. However, considering cost with Amazon EKS, it may be pretty high, but it serves its purpose very effectively without management overhead.

If you are going with Amazon EKS, you must change your deployment strategy and develop applications for Kubernetes, writing deployments and pods, or stateful sets, which provides more flexibility. There are pros and cons to both solutions, and you have to evaluate which will suit your use case. In our situation, we had some applications in ECS as in Amazon EKS, and that was an architectural decision discussed internally within teams.

The initial setup with Amazon EKS was hard initially, but being accustomed to it now, it's not that difficult; it's relatively easy.

We have seen ROI with Amazon EKS; we have a separate team actively working on it. We have cost explorer available, and a bill forecast based on usage allows us to determine whether resources are underutilized or overutilized. You can generate reports and analyze them. I have done this for ECS, but for Amazon EKS, I haven't worked on cost savings directly, as there is a separate team responsible for that.

My experience with pricing for Amazon EKS is limited as there's a separate team for that, and I do not have much knowledge of specifics. However, the pricing is based on the instance type we use in the EKS node group, so it should cover that aspect; their pricing is generally easy to understand in terms of instances.

We are using a cloud deployment model. On a scale of one to ten, I rate Amazon EKS an eight.

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.

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.

I use EKS as an application management system and a second application server. It's connected to Amazon RDS. 

EKS has security features that you can't find in competing solutions.

I'm having difficulty getting my AWS clusters to communicate with my local machine. 

I have used EKS for three years.

Amazon EKS is scalable. We have about 20,000 users. 

Setting up EKS is simple compared to OpenShift. It isn't too complex. We have a hybrid setup due to government data rules. I deployed EKS alone.

I rate EKS seven out of 10 for affordability. Amazon EKS costs us $730 a year. 

I rate Amazon EKS nine out of 10.

We run all our microservices across the globe with Amazon EKS. We also use it for development, testing, and maintenance.

In the past, we have faced challenges with scalability and maintenance while running clusters. Amazon EKS is very easy to maintain. So it allows us to focus on our deployment.

The most important aspect of Amazon EKS is that it is easy to set up and very easy to upgrade. So we can focus on maintaining and deploying our microservice. It is also easy to scale and easy to monitor.

Amazon EKS provides very minimum information during the upgrade of the node group. When the upgrade doesn't work well, it doesn't give enough information for us to troubleshoot. So it would be great if Amazon EKS provided more information in such cases. 

Amazon EKS should enable some AIOps.

I have been using Amazon EKS for the past three years.

As a Kubernetes-managed platform, it is pretty stable. You can stabilize the new version when it is available in AWS.

It is easy to set up, and the Amazon EKS control plane accommodates scaling.

Whenever we experience any challenges, we always get a very fast response from AWS support. We are happy with the support provided so far.

We shifted to Amazon EKS because we faced some issues with our old system on OpenShift. OpenShift also has a high license price as compared to Amazon EKS.

We had some challenges at the beginning. It took us a few weeks to get one cluster up. Later, we improved our approach by using Terraform to manage it. Now, we can set up many clusters within one or two hours. We use around 60 clusters now.

We implemented it through our in-house team.

Amazon EKS is very cost-effective. I rate the pricing a ten on a scale of one to ten.

Other teams in the organization are trying to explore Google Kubernetes Engine. However, for our team, AWS is a lot easier. Our team might not move to other cloud providers because running Terraform is very useful for us.

In the internal cluster, we have four hundred people working with Amazon EKS. We have a lot of customers running billions of transactions. Overall, I rate Amazon EKS a nine out of ten.