They could add logging features. At present, we use external tools to increase and decrease the number of instances.

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.

Assigning roles and responsibilities to interact with a created cluster as a user over a command prompt is cumbersome on AWS. Initially, we create a user to interact with a cluster. Since everyone can't use the cluster, we need to assign some permissions to that specific user. It is very cumbersome to assign permissions to users to interact with a cluster. We always get errors, and it takes many days to resolve that permission issue before the user can start interacting with the cluster.

Amazon EKS should improve its integration. Our company does not maintain the external infrastructure.

Amazon EKS should include a graphic interface. Like there is a dashboard in Kubernetes, Amazon EKS should have a graphic interface that is more fluid, more fluent and contains more information.

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.

When it comes to Amazon EKS, there are IAM permissions and RBAC. When you create an IAM user, you give the privileges on the cluster level, but there won't be anything inside the clusters. In the clusters and their respective files, you will have to map the IAM user created with the help of AWS. The documentation part of the product is an area of concern that needs to be made easier from an improvement perspective.

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

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

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

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.

An area for improvement in Amazon EKS is the user experience. The platform could be more user-friendly. Only an expert can manage and use it.

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. 

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.

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.

If you compare Amazon EKS with OpenShift, the latter provides users with a solution that is fully managed through automation. Amazon EKS is not a solution that can be fully managed through automation, making it an area of concern where improvement is required. Amazon EKS should be manageable through a web portal or web interface, a feature that exists in OpenShift.

Amazon EKS should be available as a fully managed service since we use Helm chart to deploy the product in our company right now.

The initial setup phase of the product is an area where certain improvements can be made.

The connectivity could be better.

The product’s pricing needs improvement.

Amazon EKS's vulnerability management of data could be improved. Also, concerning vulnerability and version upgrades, many more things could be pulled into the control plane rather than keeping it in the data plane and having the users figure out how to upgrade their portions.

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. 

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

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

The tool's setup is complex. 

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

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 encountered problems with the product’s documentation. Additionally, the CPU consumes a lot of memory. EKS could be modular like GCP as well.

It is challenging to host the applications in the existing VPC of the solution. They should include some essential configuration features to it.

The managed services of Amazon EKS could be improved. The system should have a closed-loop feedback mechanism to address any issues that users may face.

Moreover, the overall stability of the product should be improved to prevent any loss of data.

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

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

There isn't something that is unique or outstanding. 

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

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 would like to see it a little more stable, more operational, and more convenient to develop.

Amazon EKS needs to improve customer operations and technical support. 

I would like to see the user interface improved because it is hard to find and not straightforward.

The graphical user interface could be better.

I'd like improved traffic handling and additional application details within the system.