Amazon EKS Reviews

Our primary case is using Amazon EKS with all of our data in our MapReduce, map clusters, and our data clusters. And from there, we just input the information using Python and do our analysis using that.

We have problems with setting up virtual environments and installing the right packages. I believe the initial setup could be a better experience and faster customer support.

I have been using Amazon EKS for the past one and half years now.

The stability is excellent.

The scalability is not a problem we currently have five to six thousand employees using Amazon EKS.

Technical support or customer support is good but could be faster.

For us in our company, it is a very straightforward process because they had built a layer that is very useful for the users with just a couple of clicks. But normally, if you ask me in person, I think it is a bit cumbersome.

It can be done in-house but they have to read a lot of documentation from the AWS provider in order for it to make sense.

When you compare it to on-premises it is much better because, with on-premise, we have to look into data security and all these items. Amazon EKS eliminates that and becomes a cost-benefit for us.

On a scale of one to ten, I would give it a six. With the correct technical support individual, you can do well with implementation. If you are not sure about the technical support side for implementation I would wait until you are ready.

We are using EKS for crypto exchange. 

We chose this solution because with crypto exchange you need high performance and easy manageability. It offers highly available architecture, and with two or three Linux servers it distributes all containers through the Linux systems. If that's what you're looking for, it's a really good solution. It also allows for integrating their infrastructure as service capabilities. 

The only important thing that needs to be improved is the EKS dashboard. It could be more user-friendly. 

We've been using this solution for about six months. 

The solution is stable. 

The solution is very scalable. 

We're very happy with the customer support. 

The initial setup was average in terms of complexity. We have one very good system admin person in our company, he has a lot of experience and carried out the deployment. We are still in a testing environment, so there are only around 15 users. We have around a million users and eventually they'll all be using it. 

We pay a monthly licensing fee which is quite high but they do provide good service.

I rate this solution eight out of 10. 

Amazon EKS is for storage, services, and infrastructure. We have about 100 to 120 users on Amazon EKS right now. We'll likely expand by 10 or 15 percent in the next year depending on our customer needs. 

AWS cloud services are flexible and have thorough documentation. AWS also has data centers all over the world.

I would like Amazon EKS to be easier to configure on various environments like Windows or Linux installations

I've been using Amazon EKS for five years.

We use AWS in parallel with other cloud service providers from different vendors, like Azure and GCP. We are not the end customer. It's something we use to deliver services to our customers. We work with a wide range of technologies at the company, which employs around 500 plus people. They work with all major technologies currently available.

Installing Amazon EKS is straightforward. It depends on what needs to be done, but it's not something that takes weeks to deploy. You can do it in a few hours or days. I would need to have a specific scenario to be precise because the steps vary in each installation.

I would like Amazon EKS to be cheaper. Otherwise, it's fine.  

I rate Amazon EKS eight out of 10. 

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. 

I have tried to host the enterprise content management application of IBM FileNet on Amazon EKS. That's the main use case. 

The solution has very good basic features.

The provisioning is very good we use it for the containerization of COTS applications.

The product is stable. 

If a company needs to scale the solution, it can.

The initial setup is simple. 

We've found the solution's technical support to be helpful and responsive.

There isn't something that is unique or outstanding. 

I'd like to see the solution add a service catalog.

I've used the solution for quite a number of years. It's been around three so far. 

We've found the solution to be stable. Currently, it's used on standard VMs. If we put it on Kubernetes clusters, it is highly reliable as well as easy to monitor, manage, and operate. It's great.

The solution is absolutely scalable. There are many enterprises running their businesses on this.

I'm not deploying anything for customers or a certain number of users. I'm just doing it for my own purposes. I'm learning about it and I'm trying new things. I propose these ideas to customers for various solutions and the implementations are done by another team, the delivery team, later. I can't speak to how many people ultimately end up using it.

Technical support is very good. There is no issue. There's no delayed response for their support. There's no lack of support. They are very helpful and we are quite satisfied. 

The initial setup is not overly complex or difficult. It's very simple, very straightforward. The instruction guides are all available and it's enough to get a user through the setup process. They are quite helpful guides. 

We have a professional services team that does the job day in, day out. That said, I do it for my learning and I practice something on my own too. Therefore, I am also very capable of handling the initial setup myself. 

We already have costs built into the service given by the particular vendor. If it is on-premise, we buy the software, and we pay some support costs and license costs. However, if it is on the cloud, it is a pay-per-use model. 

I'm an integrator of the solution. 

The solution can be deployed both on the cloud and on-premises. 

We are using the latest version of the solution at this time. I can't speak to the exact version number, however.

I would recommend this solution to others. 

I'd rate the product at a nine out of ten. We're pretty happy with its capabilities so far. 

Our main use case is when our client or the customer would like to have their service on AWS. When the client preference is AWS.

Our company prefers Amazon EKS to ECS.

The feature that I have found most valuable is that it is very user-friendly.

I would like to see it a little more stable, more operational, and more convenient to develop.

I have been using Amazon EKS for about two to three years.

Amazon EKS is very stable.

We have about 500 people in our organization using it.

Our technical team for the deployment and maintenance is only five people, one manager and four engineers.

We are definitely going to continue using this solution.

For container management, I had been using the IBM SP solution, but frankly speaking I don't like the IBM Cloud.

The initial installation was straightforward. It took under 30 minutes.

I love dealing with EKS. Personally, I like to deal with the Kubernetes solution.

On a scale of one to the, I would rate EKS a nine.

I would recommend Amazon EKS to others.

We use Amazon Elastic Kubernetes Service (EKS) to manage our containers and to run and scale Kubernetes applications in the cloud.

Overall Amazon EKS is a good solution in the industry. The solution can support multi tendencies, and network isolations are the key factors.

Amazon EKS is predominately public. However, the government has started to have a lot of interest in Kubernetes and is receiving more education on Kubernetes and Amazon EKS. If we can have the security of Amazon EKS align with the security that is set out by the government it would be much better.

I have been using Amazon EKS for approximately six months.

Amazon EKS is scalable.

We are in the process of migrating from OpenShift to Amazon EKS which will be a lot of work to migrate over. We have about over 300 developers who are going to use Amazon EKS in the future.

We have previously used OpenShift.

I did the implementation of the solution myself in my organization.

I have found OpenShift to be a better tool and I would recommend it.

I rate Amazon EKS 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.