Amazon EKS Reviews

I have clients that run on Kubernetes engines. 

The tool works well with the nodes in AWS. It's scalability is also good in terms of architecture. 

I am not impressed with the tool's Amazon console. It also needs to add security features. 

I have been working with the product for four years. 

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

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

The tool's premium support is good. 

Positive

The solution's deployment gets completed in minutes. You need one DevOps engineer to maintain the solution. 

The solution is pricey. The tool's pricing is monthly. 

I would rate the solution a ten out of ten. It is the best platform for Kubernetes. The tool is also compliant. You need a demo to get started with it. 

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.

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. 

The value is for me that it's a community product. We don't have to rely on the ECS services. 

What is new right now is Fargate. Fargate has the ability to abstract from the clusters. Amazon said that using the cluster is too complicated for people. Therefore, what they do right now is they have a service that sits on top of the cluster that doesn't even know it's a cluster. It abstracts it for you. Fargate is the ability to deploy it into the cluster, which specifies what you want to deploy and it takes care of the cluster provisioning and deployment for you. The tool just abstracts you away from the cluster, so you don't even know that you're using a cluster, which is good for people that don't want to learn the technology, the infrastructure.

The solution is easy to use. You don't have to care about the servers or the cluster. You really just say, I want to deploy this application A. You just find the application, click a button, and Fargate deploys it to a cluster for you.

They really want to get away from the idea that you made your own cluster. They really want to push you a bit higher up the layer, more of an abstraction layer.

Due to Kubernetes, it's easy to move between the clouds, to move those jobs, especially in multi-cloud systems right now. So one of the disadvantages of EKS is because of the technology they use for their machine learning right now and we prefer to have options, like CPU and Google.

When we switched to EKS, historically it wasn't good. There were issues with bugs in it. They didn't have managed pools, which means small subsections of the clusters that you divided into pools like a mini-cluster in your cluster. However, now they have managed pools.

For the last several versions, the issue was with their kind of networking plug-in, the security plug-ins, and things like that. That EKS layer on top of the Kubernetes, they add themselves to each cloud, however, only with fewer standards and a little more issues. They need to work on the Amazon plugins on the Kubernetes cluster.

We just updated to a cluster 1.18, but we were on that cluster 1.13 which had many bugs and issues. Moving up to 1.19 in the middle of last year, we had some issues which they had to fix.

One thing that is probably not the greatest in Amazon is the ideology. They really want you to stick to cloud tools. They want you to use the managed version of the databases and our preference is to use the Kubernetes-managed databases. This doesn't fit well with the AWS philosophy, which is then passed on to the AWS engineers and they push that, push ideology on us as well, saying "You know what, we want you to use this database."

We're not dogmatic. If they want us to use a specific database, we use it, as the cluster is very dynamic. We don't need to deploy a database within a cluster, we can use the cloud database. To us, it's just a connection string, so it's not inefficient for us. It's just based on the client. However, you can see there's a little bit of an ideology dogma baked into the AWS philosophy just to keep you in the cloud. 

We've used the solution since it began. It's been a while.

Older versions haven't been so stable, however, they have been working on improving the latest solutions and it's getting much better.

The Kubernetes cluster is developed outside of the cloud, the core of it. The core of it has gotten much better and all the plugins that Amazon did, also have gotten better as well. One kind-of drives the other. It's a revolving, iterative process. You just have to be proactive and keep on updating your versions and manage your cluster a little bit better every time.

We don't have to deal with technical support at all. We haven't used them in the last six or seven years. There's nothing fundamentally wrong that we've found over the years that we have to call support. Almost everything is self-explanatory on the website. There really isn't a need to talk to them directly.

I also have some experience with Kubernetes and Google Cloud. Google Cloud has something called Google Cloud Run, which is very similar to Fargate. Both are trying to make your life much simpler so you don't have to look at the bare-bones infrastructure. It's easy.

The solution offers different pricing models. They charge in different ways  - either per CPU hour or usage based on a machine type. When it comes to pricing, Google may be two cents cheaper, whoever, the difference makes it a bit of a wash. It might mean an extra five dollars or 20 dollars a month. The difference isn't enough to be too noticeable. All of the main competitors charge very competitive pricing. 

That said, when it comes to the CPUs, that's a Google proprietary technology. When we do machine learning, we do prefer working in Google Cloud, as we have the option to expand all the way to CPU and AWS doesn't have that option. It's a GPU-only system. Amazon's also pushing you towards their own machine learning tool, SageMaker, which we don't want to use. We want to use our own tool.

We're not on the latest version. We are three or so versions back.

However, we're almost on the latest version, which may be 1.19. The version's no longer an issue. For us, the issue was that Amazon started with the ECS, the Elastic Container Services. Therefore, while we were using Kubernetes and then Google Cloud, for example, for a while and we had developed all the tools when a client came to us and said they wanted to cluster within the Amazon development cluster. That was the ECS. After that, Amazon added the EKS. Our first deployment in Amazon was on our own deployment of the cluster, not on any services. We didn't want to use the ECS, we wanted to use a cluster. We wanted a managed version, so we don't have to manage it ourselves, due to the fact that it's a little bit of a mess if you manage it.

I would advise new users to make sure that your cluster's secure. Make sure you're using a good networking configuration in your EKS. You need to get the NAT and the router going just on the subnet. You might have to pay for that. There are open-source tools to use, however, you can also pay for their monitoring.

When you have a development pipeline, we suggest having multiple clusters, not just one. Then you can really isolate your production cluster and make it really secure and maybe relax a little bit for your DEV and then QA, as you might want to have more things in there. You just need to make sure you remove those tools from your production box.

It's easier to have multiple clusters and really partition the cluster per environment, development, QA, testing environment, integration testing, whatever, and then you have your production environment, which is really kind of locked down so that nobody has access to it except specific people.

In general, I would rate this solution at an eight 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 basically a model provided by Amazon that allows you to create and deploy multiple microservices and manage containers. Once the Kubernetes is installed, we can directly create the container, set up ports, and set up new services. We currently have Java containers running.

We have more than 500 people using this solution. We are on version 21.

I like the scalability they're currently providing. Integration was very easy. It was a good experience. 

The connectivity could be better.

I have been using Amazon EKS for more than two years.

It's stable enough. We have had network connectivity issues twice. We weren't able to figure out what went wrong there, and it caused a problem initially. When we restarted it, it began working again.

The scalability is good.

We have called technical support a couple of times. We had an issue with integration with Lambda. But we took the help of AWS and it was resolved.

We have also used the IBM private cloud, but it wasn't user friendly.

Setup can take half an hour to an hour.

For deployment, our technical team was made up of 15 people.

My company paid for the license. 

I would rate this solution 8 out of 10.

I would definitely recommend this solution. It's a very good application, and the scalability is very good.

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.

Our primary use case for Amazon EKS is for running production workloads. The microservices-based modules are broken down and then hosted using EKS.

The most valuable feature to us is orchestration when it comes to deploying. The main ideology behind Kubernetes is that you are breaking down your application into smaller modules. Instead of having a monolithic application, you make it a microservices-based module. Using an e-commerce website as an example, we would break down login's as a single module, registration as a single module and then in the event of an issue one does not impact the other. 

With your small modules, in most cases, they share a backend, and that's how at the service layer you connect them by using an API gateway or a service mesh. This ensures scalability and they don't have any dependencies when it comes to failures. This means you can easily scale and optimize. 

For now I can't suggest any improvements or additional features, the features we currently use we are very happy with. 

We have been using Amazon EKS for 8-9 months.

The Kubernetes solution has been very stable for us, there are no issues to report on that aspect. 

The beauty of Kubernetes is that you can scale it. You just have to define the workload and the scalability capability is managed itself. We just need to define the number of bots or services we want to run and it manages to scale up when needed. 

We have found Amazon to be quite responsive. We have experienced some minor issues and the response time was good. 

With regards to setup, you would need to have a basic understanding of Kubernetes and how it works before you start deploying your production workloads. Once we started working with Kubernetes and got hands-on experience there was not much hassle to roll out to production workloads.

There is no up front licensing cost, as this is a cloud based solution you pay-as-you-go.

The advice I would offer on Kubernetes is with the configuration of your applications. Some are compute-extensive, some are compute-optimized. If you don't configure this correctly it can lead to deadlocks. The compute power has to be enough when it comes to your applications. Some applications need more memory, for example, e-commerce sites need a good response time. In this example, you would want to configure a memory-based application.