Amazon EKS Reviews

We mainly use EKS for containers. We use Kubernetes for scalable deployments.

We're using EKS because our customers requested it. They wanted autoscaling functionality. We have our own product, and we deploy it for our customers in Amazon cloud.

The containers are built, registered, and then kept in a repository at the docker site. Our IT department has an account there. From there, it's exposed and we use the Amazon template surveys and cloud formation template. Then, our IT team creates CFTs. The scripts are run, and the containers are deployed from there.

It's a hybrid solution.

EKS provides autoscaling functionality.

I started using EKS about eight months ago.

It's reasonably stable. EKS is used with Fargate.

From what I understand, it's scalable. I haven't heard of any issues.

Setup depends on what kind of architecture you have.

It depends on the script that's prepared. Once the script is done, just one person is needed for deployment.

We have an internal team that takes care of deployment. They're a specialized team.

I would rate this solution as eight out of ten.

My advice is that not every architecture can fit into EKS. You have to really evaluate whether EKS is suitable for the kind of design and architecture you have. Evaluate it first and then attempt it.

We just implemented the acquisition project for our cloud application environment, and we implemented Amazon EKS.

The most valuable feature is the cluster engine. It is also a feature in Kubernetes clusters, and we can't differentiate between the benefits in Amazon EKS and Kubernetes.

They should improve the security and include some cloud-native project integrations. In addition, they should enhance the Jira integration.

We have been using this solution for about two years, and it is deployed on cloud.

It is a stable solution.

Amazon EKS is scalable. When the usage increases, the EKS clusters immediately increase the number of ports and cluster nodes. Amazon EKS is ready for implementation, but the implementation depends on the number of clients. Our target is to increase our clients, and when that happens, the use of Amazon EKS will increase.

We have not needed technical support.

There is no installation required, but some implementation procedures and configurations are needed. The configuration is simple because Kubernetes manage it, and we do not drive all the Kubernetes clusters using a command line interface. We drive all the management activities with a user interface.

It's a subscription and depends on the cluster nodes and other effects. There are many calculation criteria for licensing.

There are a lot of criteria affecting why we switched to Amazon AWS. In addition to its features, it has computing services and app store services.

I rate the solution a nine out of ten and recommend it to others.

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. 

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.

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.

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. 

The product helps to create a new environment fast. 

The tool helps us to provide greater access and also scale applications faster.

The product helps us to configure the new environment. 

The tool's setup is complex. 

I have been working with the product for three years. 

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

I would rate the product's scalability a ten out of ten. My company has around 1000 users of the tool. We have plans to increase the usage in future. 

The tool's setup is difficult and requires experienced people. 

I would rate the tool a ten out of ten. The product is very easy to use since it is based on Kubernetes. It is a great tool for complex environments with multiple applications.