Amazon EKS Reviews

I have a total of around four years of experience in multiple clouds, especially in AWS, and many times I used Amazon EKS for our multiple products and projects.

In our environment, we already have all the other infrastructure and services running on AWS, so we benefit from using Amazon EKS because the other services can easily communicate with it. For example, some of our services need to access S3, and our application objects reside there, so we can easily integrate them with Amazon EKS. We also use IAM rules for integration to provide granular access to resources. As per your question, in our environment, most of our clients and resources reside in AWS, which is why we prefer to deploy other services there, as most of our development environment uses Lightsail. This gives us an edge, allowing us to easily move from development to staging or production environments within the same cloud.

When we compare other clouds, AWS has an edge among all the crowded options right now. My observations and reviews with AWS also affirm this because it provides a user-friendly experience and offers many options that other clouds do not provide. When my team and I work with AWS, we always feel comfortable. I do not know the exact reason behind it; maybe we have a lot of previous experience, and we are familiar with AWS. That is why other reviews from my colleagues at previous companies indicate that AWS has some edge compared to other clouds.

I would recommend Amazon EKS to other organizations because it provides simple configuration, easy management, safety, granular access, and vast monitoring capabilities where we can easily monitor our clusters using CloudWatch. However, I would think about a clearer dashboard for Amazon EKS, but overall, I think it is sufficient.

When we need to deploy the application, we require a large number of instances. Therefore, I hope and believe I will not face out-of-capacity issues in AWS, especially since I have not yet experienced traffic around 50,000 plus, and I believe I will not face such issues in Amazon EKS the next time we deploy with a large number of nodes and worker nodes.

Additionally, the upgradation process of Kubernetes rapidly rolls out new releases, so it should be easier for our production environment to upgrade Amazon EKS clusters. Sometimes when we are going to upgrade the Amazon EKS cluster, we need to check the backups, and we should have options to export our configurations, such as exporting the configuration to S3 or somewhere else to find backups. Other tools, such as Velero, provide this functionality to back up configurations, so I hope this backup process will help us fulfill our backup policies and other requirements.

For the pricing aspect of Amazon EKS, one specific issue arises when we deploy applications, especially as we provide SaaS services to our clients. We would like to know the cost for each customer, but we face issues because AWS charges $70 USD for the Amazon EKS engine. We struggle to divide the worker nodes' fees and the engine cost among clients, as some users have low traffic and visibility while others have large amounts of visibility and traffic. Thus, we face cost-related issues when running multiple customers on the same Amazon EKS cluster.

I have been using the solution for approximately four years.

The initial setup and deployment of Amazon EKS was straightforward; I easily provisioned the correct cluster. Sometimes, due to the depreciation of the AMIs, AWS provides warnings to use the latest version of the EKS AMIs because some of our scripts or Terraform scripts are old. I think it is good practice for AWS to provide messages to the console to upgrade your cluster, but overall, my experience with provisioning the Amazon EKS cluster is good, and I highly appreciate it.

I have not faced any issues that require escalation to customer support, and until today, I do not feel any need to escalate anything to the support team. I am happy with the service.

To meet our requirements, our services need a large amount of CPU and memory, so we need high-spec machines. When we deploy applications, we require a large number of instances.

I have not faced any issues that require escalation to customer support, and until today, I do not feel any need to escalate anything to the support team. I am happy with the service.

I also work with other clouds, such as Oracle Cloud, but I feel comfortable with AWS because I faced some issues, such as out of capacity when we designed the infrastructure for our large traffic.

The initial setup and deployment of Amazon EKS was straightforward; I easily provisioned the correct cluster. Sometimes, due to the depreciation of the AMIs, AWS provides warnings to use the latest version of the EKS AMIs because some of our scripts or Terraform scripts are old. I think it is good practice for AWS to provide messages to the console to upgrade your cluster, but overall, my experience with provisioning the Amazon EKS cluster is good, and I highly appreciate it.

I used Amazon EKS through its console rather than through the AWS Marketplace.

I have not checked the pricing yet, but I will look into it to see if EKS brings ROI or a return on investment for us.

Regarding self-healing nodes in Amazon EKS, I have not worked on that self-healing feature.

For automated patching in Amazon EKS, I have not used that feature.

Regarding disadvantages of Amazon EKS compared to competitors in the market, I think every cloud provider has the same Kubernetes engine and worker nodes. However, I believe AWS provides a more user-friendly environment, which is why many of our customers are trying to deploy their infrastructure or applications on AWS. I do not think there is any specific reason not to prefer Amazon EKS.

I have not integrated IAM tools with Amazon EKS yet, but my other teams have. I think they used Okta, but I'm not certain about it. I have some demos from a long time ago, but I think Okta is for SSO.

On a scale of one to ten, I rate Amazon EKS a nine out of ten.

Private Cloud

Amazon Web Services (AWS)

We have integrated with IAM. We haven't used it in production now, but we are still in the research and development stage. We are planning to use the Amazon EKS hybrid solution by using our own data center virtual machine on our Amazon EKS clusters. A hybrid cluster would be a great solution for us since we have many resources here, and we want to utilize our cloud service. We are still in research and development solution. The only use case I can remember integrating IAM with Amazon EKS is the hybrid work for nodes.

We wanted to easily integrate our on-premise nodes with Amazon EKS to fully utilize the cloud service with our already persistent on-premise nodes. The major use case was that we wanted to host calls where the latency has to be in one digit. We can't have a call here in Mongolia jump from the Hong Kong AWS server and jump back to us. That would be a terrible experience for our users. We would have to implement the one-digit latency solution within our country, so we have to utilize the on-premise data center nodes. That was a bit of a challenge for us. Other than that, it's usually great.

For scaling our application, ensuring high availability and cost saving with Amazon EKS, the automatic load operation, no maintenance, and all features are really nice for our business.

In our old cluster, we were using on-premise Kubernetes. We had some downtimes here and there, with downtime being a monthly occurrence to our business. When we switched to Amazon EKS, we haven't faced any downtime in two years so far. That means no stop business growth for our type, and we can continue focusing on our business agility. The maintenance, configuration, and maintenance of our cluster has never been needed. We can update our Kubernetes cluster versions by just clicking one button. Before that, it was a long and tedious task. We would have to do it during nighttime operations. Operations are minimized and downtimes are non-existent now. Adding nodes and removing nodes are automatic so we could save costs there too.

The application supply chain integration has never been easier with Amazon EKS. We have integrated Amazon EKS into the CICD pipeline. Our developers are just pushing our code to our repository, and a few minutes later, it's deployed in Amazon EKS.

Mostly, it's just minimizing the manual preparations and increasing our business time with Amazon EKS so we can focus more on improving our applications and researching new ways to improve our business side. This means less time on the system side manual configuration and more time on making our applications better for our users.

We haven't fully utilized self-healing nodes in Amazon EKS yet. The self-healing nodes are still in our research and development stage. It is new we are using in production clusters.

We have been working with Amazon EKS for two years in our company now.

The Amazon EKS itself is great. We haven't had an issue with that.

We asked customer service regarding a wrong charge on our billing account, but I haven't initiated a request ticket, so I'm not very familiar with it. Our DevOps team had started the process. We reached out to them before.

It was really positive. The customer support was nice, informative, and very helpful.

Positive

I think it's reasonable. The EP two nodes are a bit expensive on the side. Other than that, Amazon EKS is pretty reasonable for its price.

We researched the pricing and how much it would cost in a month, so we are aware of the pricing.

Other than Amazon EKS, there's also GKE, the Google solution, and the Microsoft Azure solution and also OpenShift. We considered Amazon EKS because it's the most popular and widely available one. We opted for Amazon EKS because most of our engineers are familiar with the AWS environment.

We will apply it because it's easy to get out. We can easily integrate it in your application. It also has the most documentation out there. I would advise it.

Currently, we are just following the best practices with Amazon EKS. We follow the usual best practices or workflow with Amazon EKS and load balancing.

In comparison, the latency is a bit high with Amazon EKS. When we were researching about a year ago, Google offers almost forty milliseconds delay to Mongolia, as Amazon EKS in Hong Kong offers sixty milliseconds delay. That was the only downside from not choosing Google over Amazon EKS. Other than that, Amazon EKS has a lot of services.

On a scale of 1-10, I rate Amazon EKS a nine out of ten.

Hybrid Cloud

Amazon Web Services (AWS)

My use cases for Amazon EKS involve different types of workloads, mostly web-related and mobile application related, to orchestrate deployments and make application release easier, smoother, and faster.

What I appreciate best about Amazon EKS is that it's a great solution, especially for teams who search for flexibility and who are in active development of microservices architecture. It gives flexibility not only for DevOps but also for developers to control infrastructure through code, such as through the GitOps approach, which releases a lot of time and effort for system engineers and DevOps engineers to do their business and not provision servers by their own. Scalability and flexibility are the most useful cases there.

The benefits I have seen using Amazon EKS are substantial. Kubernetes is a complex structure, and if you have it self-maintained on your bare metal devices, it's first a pretty big chunk of the infrastructure. Plus, it's very complex and hard to maintain. Not all engineers have the knowledge to control a Kubernetes cluster. Having it as a service reduces release time dramatically. Amazon controls the versions, upgrades, security components, and related elements. It's easy to do system upgrades, even release another cluster in a matter of a few hours and move all workloads to the latest release of Amazon EKS if needed or for development environment testing. This would be much more difficult if you control your Kubernetes cluster manually as self-hosted.

What could be improved in Amazon EKS is the documentation. It's pretty dynamic, moving too fast, and sometimes the documentation doesn't reflect the migration between changes, especially if you use some non-native vendor enterprise components and CRDM modules. If you use only AWS UI, it's pretty hard to debug something in Amazon EKS. You need to be aware about kubectl or another toolset which allows you to dive deeper into the Kubernetes details. Not always do software developers have such expertise. If they could improve their debug capabilities, toolset for debugging, or maybe integrate it with their AI, such as Amazon Q, to support the developers, it could be valuable for developers.

I have been using Amazon EKS practically from the day they implemented this solution, which has been many years already.

I can easily scale up or down with Amazon EKS. Currently, Kubernetes and Amazon EKS itself have many different vendor solutions, native solutions or vendor solutions for scaling. It's easy to control and very cost-efficient.

The customer support from Amazon could be better. I find it problematic that customers who don't have a big budget are not able to use the customer support. If you don't have your support subscription, you're only able to use forums, which is challenging because sometimes software can have issues or the setup is pretty tricky and not reflected in the documentation.

Support quality depends on which engineers you're talking with. For bigger clients and companies, AWS dedicates an agent or manager as a point of contact for the specific team, and you can easily reach them and discuss initial key points. It's great. It doesn't always do what you would expect, but at least it's a very good and fast starting point to solve issues.

I would rate their support a seven out of ten.

Positive

I have previously used different solutions before Amazon EKS. For simpler solutions, we used Amazon ECS, which is a native Docker orchestrator. It's much simpler than Kubernetes but does the job well for a simple setup. It's a bit more difficult in the provisioning and control of components, but it works fine for static infrastructure. We used various solutions, from self-hosted Docker containers for ECS, Fargate, to Lambda functions. The choice depends on what you actually expect from your application and infrastructure.

Regarding the pricing of Amazon EKS, if we discuss EKS itself, it's relatively cheap at $75 for deployment for the control plane. However, for running a Kubernetes cluster, you need more resources even for the simplest deployment of any modules. It could be very expensive, but it's mostly about how the architecture is built and how the team controls the resources. It's not about Amazon EKS directly, but related.

I have used Amazon EKS integration with IAM. It's basically one of the core parts of the configurations not only for access to the cluster but also for the services themselves to provide them access to other Amazon resources.

My experience with the deployment in Amazon EKS is that it's easy and has many options for how you can control your deployment in Kubernetes from your native kubectl to the GitOps approach. I strongly support the GitOps approach to control everything and give developers access to infrastructure through GitOps and full code-controlled infrastructure. It's easy when you integrate everything and it works fine.

I would recommend Amazon EKS to others if they're sure that Kubernetes is what they would need. On a scale of 1-10, I rate Amazon EKS an 8.

Public Cloud

Amazon Web Services (AWS)

My usual use cases for Amazon EKS are for my company's projects, as they instructed us to set up Amazon EKS and then deploy the applications.

I use Amazon EKS mainly for my company's projects, where we deploy applications according to company requirements.

The features and capabilities of Amazon EKS have proven to be valuable, as we use EKS in most of our projects. Our company has selected AWS as one of our three cloud preferences, which are AWS, GCP, and Azure.

The specific features I find most useful in Amazon EKS include the ability to deploy our applications directly using the pipeline file in YAML, the capacity to create multiple instances, and the capability to scale as per the requirement.

Amazon EKS's self-healing nodes help minimize administrative burdens in my organization by automatically creating a new node if any node crashes, allowing us to manage only the minimum and maximum nodes as needed.

To use Amazon EKS, we create the cluster first, and then we deploy the applications using the YAML file.

I have not used the automated patching feature for my Kubernetes clusters in Amazon EKS yet.

I think if new features, especially AI capabilities, are developed for Amazon EKS, it will enhance the product as it allows us to continually improve our applications.

I have been working with Amazon EKS for the past three years.

I participated in the initial setup and deployment of Amazon EKS.

My impression is that Amazon EKS is very stable and reliable as a product.

I have not noticed any outages, delays, or downtime with Amazon EKS; everything operates smoothly.

Amazon EKS is easy to evaluate in terms of scalability; we can auto-scale easily as needed.

I would rate the scalability of Amazon EKS as a nine out of ten.

I do not often communicate with the technical support of Amazon EKS as I have not needed their assistance.

For our work with Amazon EKS, we utilize the available documentation and guides, which are useful for understanding and starting with any AI tool or prompt.

I am satisfied with the documentation that Amazon offers.

Neutral

Amazon EKS was my first Kubernetes platform. Prior to that, I had only used Minikube locally, and after that, I have worked exclusively with Amazon EKS.

During the setup process for Amazon EKS, I set it up locally by configuring AWS config, and then I focused on the necessary setups like kubectl.

To start working with Amazon EKS, I first configure it with AWS, install kubectl, and then begin working after creating the cluster.

I chose Amazon EKS to work with because I have not yet started using GCP's or Azure's Kubernetes services. I have experience only with Amazon EKS so far.

I have only worked on one application in Amazon EKS, so I haven't fully developed it. I have only deployed the front end, and I think I need to gather more knowledge about EKS.

The interface of Amazon EKS is very good, but I prefer to use the CLI for creating clusters. I initially used the UI just once to understand everything before starting to create using the CLI only.

On a scale of one to ten, I rate Amazon EKS a nine.

Public Cloud

Amazon Web Services (AWS)

The use case for Amazon EKS is that we have our multiple pods and services running on the particular microservices application, so we have to integrate and auto-scale the Amazon EKS cluster from the Amazon EKS cluster and pod management services.

If any traffic increases on the application, we have set the load balancer and auto-scaling via the Amazon EKS cluster, the managed cluster.

The value of Amazon EKS for us is due to our microservice-level architecture, where we need to automate and have a fast, scalable application, allowing us to directly configure the Amazon EKS cluster in the application, which will make it very easy to run our application smoothly and scalably.

Amazon EKS's self-healing nodes help minimize administrative burdens in my organization by automating through all of Amazon EKS. We have used multiple types of automation tools which we directly integrate for the deployment purpose of the Amazon EKS cluster. We have integrated them with the Docker side of Amazon EKS, allowing the container service to run over there, so it is directly deployed for the administrative level of the Amazon EKS cluster.

The benefits I have seen from Amazon EKS include a fully managed Kubernetes service for the control plane, the API server level, etcd scheduler, and controller. There's no need to worry about patching, scaling, and maintaining the master node. There is high availability over multiple availability zone control panels, and security compliance is guaranteed for IAM; AWS IAM users authenticate and access the control from the support VPC isolation and security group network policy.

The integration with IAM helps enhance our authentication process because IAM basically helps with access. Nobody can enter with any kind of access, and any kind of vulnerability will be showing in my application. If I set an IAM user to that Amazon EKS cluster, that user will have limited access, and that application will run through that IAM user only. It is very beneficial, and for security purposes, it's also important because vulnerabilities will be found and block all the vulnerability and security issues if you set an IAM user to the Amazon EKS cluster with limited access.

We have not automated patches to be applied for the Amazon EKS cluster because it will resolve live production services. We directly and manually configure and update those patches if any patches are required for the particular application.

I did not configure all related applications since we are running only one application, which is good from my end. To improve the regularity, the IAM Access Analyzer could detect risk permissions, so the IAM Access Analyzer could be applied for this.

From all the AWS services we are using, I have been working with Amazon EKS for the last three years. In that EKS, I've been using it for only one application that will be running over there, so I've been using it for nine to ten months, probably one year.

I have communicated with the technical support of Amazon EKS. When we were trying to configure the Amazon EKS cluster for the first time, we used technical support. If there is any kind of debug or related issue that we cannot find from our end, then we can go directly to the support team for Amazon EKS. It's very helpful and needful; whatever kind of issue we are facing, they immediately tackle it, debug that issue, and resolve it as soon as possible. We have found some related networking or triggering issues on the application side, and that issue was resolved from their side as well. There is no issue from the technical side support; it's always beneficial and helpful.

Amazon EKS is stable and reliable. The control plane is fully managed by the AWS service, so there is no need to run the Kubernetes master, which is very reliable. There are multiple availability zones in the regions, meaning no single point of failure, and 99% of the time, our application will have uptime with the Kubernetes API server.

Amazon EKS is highly scalable; as per the node cluster, it will provide EC2 or Fargate up to 10,000 nodes. It's a very scalable cluster, fully controlled by the Amazon EKS plane.

The support of Amazon EKS for AWS tools integration influences my application development and management process because it is on the AWS side, and the Amazon EKS managed cluster is provided from there. We didn't need to manage etcd and those control management tools; it's totally handled from the AWS side, making it very beneficial. We just monitor and configure all the related services and manage them via the pods and cluster-related aspects, while all the configuration support and configuration-related things via the control plane are directly managed by the AWS side of the services, which is very beneficial for us.

Positive

Before Amazon EKS, we did not use a different solution for these use cases. We are directly running on it. If there is any application running on a small-level architecture, we can directly build as per the build process. We follow the build process step-by-step to build our application via the production environment as well, without any Amazon EKS cluster.

We did not participate in the deployment and the initial setup of Amazon EKS; we are using it as per our need. We have an AWS service account, so as per our need, we are using those services. For whatever AWS service we have to use, we have a paid service account, and as per our need, we directly use it.

I am aware that pricing for Amazon EKS should be based on the cost structure, where what cost is planned depends on what we are using and serving on the instance. We have applied tag resources, depending on what kind of services we are using, and they provide the cost as per the service. It would be better if, when the application is running slower, the price would be less than that application; it could be implemented in the future.

Before choosing Amazon EKS, we did not evaluate other options or other vendors; we have not worked with any other tools till yet. We can directly deploy our application via Kubernetes and Docker, Docker, and Docker Compose files, and Jenkins via the automation.

With the IAM service, we have assigned an IAM policy, IAM user, and policy with limited access for that IAM user as per the needs of the application.

In my opinion, Amazon EKS is very good. It's very easy to monitor Amazon EKS, and the highly built architecture will be smoothly running over this Amazon EKS cluster.

On a scale of 1-10, I rate Amazon EKS a 10.

Public Cloud

Amazon Web Services (AWS)

I am currently using Amazon EKS to host our applications to provide scalability and security.

Amazon EKS is providing auto-scaling, which is one of the features that everyone is moving to because it eliminates the need for manual deployments on EC2 machines or on Docker.

Kubernetes manages all those things, which is why people are moving to Amazon EKS. For Kubernetes as a project, it can be difficult to manage, but that problem is solved by Amazon EKS so I just need to think of our application rather than the infrastructure, and AWS manages all the infrastructure.

Because of Amazon EKS, if I do manual deployment on Docker and my particular container fails, I will not know the reason. However, Amazon EKS automatically restarts that particular container or stops it and creates a new one, switching the traffic accordingly.

This is why Kubernetes provides a better experience. Amazon EKS provides scalability, which is one of the features everyone is using. In case of high traffic, it automatically scales the nodes and pods, and we can scale it horizontally or vertically.

The authentication process means that with IAM policies, I am giving the least privilege access so only particular persons are able to manage Amazon EKS clusters. Everyone does not have access, which creates a kind of zero-trust security.

In a minor enhancement sense, I just needed some documentation on that, which has already been provided, but in simple English language that is easy to understand for freshers as well.

I also needed to have some infrastructure to do some practice sessions before we could move on, because the pricing of Kubernetes and Amazon EKS is too high. For some people, it is hard to get hands-on experience with those.

I have been using Amazon EKS for almost 1.5 years since I joined the cloud infrastructure team.

I would rate Amazon EKS around 9 out of 10 for stability. It is stable.

I did not need to communicate with the technical support of Amazon EKS yet. I have not communicated with their support specialists for Amazon EKS, but I did for other things.

Before Amazon EKS, I used manual deployments such as getting the code and running those on servers. Then Docker containers came into place, running code on Docker, followed by using ECS, and then Amazon EKS came into play. It was a logical update that I chose to go with.

I participated in the initial setup of Amazon EKS in the deployment process at my previous organization. For the initial setup, there are types of deployments for Amazon EKS cluster. Via the console, it is somewhat difficult, but via CLI, it is easy. You just need to set up AWS CLI and configure it, and then a simple command is AWS EKS CTL create, and we can create our Amazon EKS clusters. It is straightforward and not complex.

When purchasing Amazon EKS service for my application, if I have only one or two pods, I need to pay 75 dollars per month for that control plane regardless of what I am hosting, which can be challenging for small-scale companies. For small-scale companies, it is a challenging situation.

Let me provide some additional context. Jenkins is one tool to consider.

AWS DevOps is also available. For monitoring, Grafana and Prometheus are options. There are also some open-source tools that we are working on, such as Signoz.

Microsoft Entra ID is one of the products which we are using. For AWS, we are using AWS ECS, Amazon EKS, IAM for authorization and authentication purposes, and databases. All the services which are on AWS are being utilized.

Amazon EKS is different from Kubernetes because it is a platform built on Kubernetes but managed by AWS. Amazon EKS is already dominating the market more than others, so there is no enhancement from my side.

I utilized Amazon EKS's integration with IAM and OIDC. IAM roles have provided the capability to give permission to Amazon EKS that this particular Amazon EKS is able to access particular services such as the S3 bucket, which is one of them, and RDS, which is a database. We are providing roles to Amazon EKS clusters so that on our behalf, it can access these particular things. By that, they can access the database and objects in the S3 bucket.

I am not currently using Amazon EKS's self-healing nodes. In another organization, we are not on Amazon EKS.

For the nodes, I can tell that it provides auto-scaling to minimize and maximize the number of nodes as traffic comes. By that, the pods will run on those, and if there is any failure on nodes, it gives another node.

I would rate this product a 9 out of 10 overall.

Public Cloud

Amazon Web Services (AWS)

We have been working on a use case where we need to deploy an application in Amazon EKS, which is a Kubernetes cluster. Kubernetes is a managed service provided by Amazon, and if we want to deploy any applications in Amazon EKS, such as application A, I want my application A to be more scalable, more tangible, and I want to deploy this in an Amazon EKS cluster. Then I check for any open source Helm charts, configure them, and deploy that Helm chart in the Amazon EKS cluster. This is how our day-to-day work goes. In general, we also deploy applications such as Apache Spark in the Amazon EKS clusters.

The features of Amazon EKS that I find most valuable include IRSA and IAM Roles for Service Accounts. While creating Amazon EKS clusters, Kubernetes offers a feature where we need to create an OIDC provider. Once configured, the authentication and authorization in the Kubernetes cluster is done by service accounts. Through the concept of service accounts, all the pods utilize IRSA, which is called IAM Roles for Service Accounts. By integrating AWS IAM roles with Amazon EKS service accounts, we can leverage other services from Amazon EKS. For example, if we want to access S3, Secrets Manager, or EC2, the concept of IRSA helps us integrate with external services of the Amazon EKS cluster easily. Additionally, Amazon offers Karpenter for scaling workloads and minimizing billing, along with managed node groups and advanced scheduling to manage our pods on different node groups.

To measure the impact of Amazon EKS on my customers' ability to manage complex workflows effectively, scaling in and scaling out is one of the key aspects for us. Since all our workloads are batch workloads that are intangible and unpredictable, we cannot keep nodes stale 24/7. Accordingly, scaling is of utmost priority. The appropriate node must spin up based on the workloads created at a given time, and pods should schedule on that node so that workloads run. For instance, if there are no workloads, there is no reason to maintain 100 nodes in the cluster, so scaling in and out is essential for not wasting resources or budgets.

One area of Amazon EKS that could be improved in the future is related to the behavior of the cluster autoscaler. We need enhancements so that scaling in and scaling out happens more effectively. Currently, the cluster autoscaler lacks visibility on the Kubernetes labels of a node group. The cluster autoscaler should at least be able to check the labels of the Kubernetes nodes, which is a necessary feature.

My experience with Amazon EKS is three years, and it has been very interesting to understand and easy to collaborate with other AWS services. It has been good working on Amazon EKS for the past three years.

Initially, I did not face challenges with the deployment of Amazon EKS, but I was not very familiar with Kubernetes initially, so it took me some time to understand Kubernetes first. The platform could be anything, including EKS, GKE, or AKS, but understanding Kubernetes was the first step necessary. After gaining familiarity with Kubernetes, Amazon EKS provided me with a good platform to work on, and I later cleared my CKA certification with a 95 percentile.

My impression of how stable and reliable Amazon EKS has been for me is positive. The upgrade process is also very fruitful, happening swiftly and without hassle or issues, so I have not faced numerous challenges. Moreover, the control plane is quite stable in Amazon EKS, and I find it to be 100% available.

Self-healing in Amazon EKS refers to what happens if any node becomes unreachable.

In our case, while I am not much sure about self-healing nodes, we utilize the cluster autoscaler in Amazon EKS. If any node is not ready, the cluster autoscaler ensures that it is removed from the AWS auto-scaling group and replaces it with a new node in the cluster.

My interaction with technical support and customer service at Amazon has been generally helpful, but they sometimes do not provide direct solutions. They tend to divert the conversation before giving a solution, which would be easier if they provided direct answers.

Once, we faced a situation where an EC2 instance got deleted due to unforeseen reasons. We reached out to support and inquired about the possibility of restoring our instance. They informed us that there was no possibility to bring it back, which felt like a dead end. I believe there should be a recovery solution available for at least a few hours so that we might bring it back; instead, we had to start again from scratch.

Positive

I usually participate in the deployment and setup of Amazon EKS. We create Amazon EKS clusters from scratch, deploy applications, and integrate them with all the AWS services.

Within the last 12 months, I have only been working with Amazon EKS. Currently, I have not been working with anything else other than Amazon EKS.

For the automated patching feature of Amazon EKS, we currently use EKS baked AMIs, which are straightforward to integrate with the Amazon EKS cluster. If we want to add additional packages or anything by boot time, it is very simple to do so while working with Amazon EKS. We can utilize a user data script to perform any patches, software upgrades, or installations, all accomplished at the instance creation time using EC2 node templates.

On a scale of 1-10, I rate Amazon EKS an 8.

Public Cloud

Amazon Web Services (AWS)

We use Amazon EKS mostly for deploying production workloads, and there are multiple AI models that we run on Amazon EKS.

My favorite feature of Amazon EKS is the ecosystem that it provides, including the integration with S3, along with EBS, and the networking that is smooth to run Kubernetes.

I have experience with Azure, and in comparison to Azure, a downside of Amazon EKS is that even if you want to deploy a dev workload or do some experimentation, we have to pay the charges for the control panel with no free option.

Additionally, I have faced many issues while configuring the node groups and the whole configurations; bringing up the nodes was a bit hectic, and I was not able to determine which node was failing and for what reason.

Specifically, the pricing for the control panel of Amazon EKS is hefty, and there is no cost-cutting that can be done on that side.

I have been using Amazon EKS in my career for four years overall.

Amazon EKS is pretty stable, and I have not seen any lagging, crashing, or downtime.

Amazon EKS is good in terms of scaling.

I have contacted technical support and customer support for Amazon EKS.

Positive

I have used Azure EKS, Civo, and also experimented with GCP as alternatives to Amazon EKS. If I have to rank between all three of them, GCP comes at number one, Amazon EKS comes at number two, and Azure EKS service comes at number three.

On the costing part of Kubernetes, Azure is beating Amazon EKS since I can do some experimentation without paying for the control panel; I can just pay for the node groups, which is an area where Amazon can improve.

From my point of view, the initial deployment of Amazon EKS is difficult.

I had to configure many components, such as IAM policies and other things; it was not a simple click-through process. The major issue is that there is no single point where I can see all the logs; while there is CloudWatch, it is not easily accessible, and you have to go through a hectic process to search and find information. There is nothing where you can go and click to get all the logs in a single place.

Amazon EKS requires maintenance on my end to continue functioning; we have to do upgradation from time to time since every Kubernetes version is only valid for one year.

On a scale from one to ten, I rate Amazon EKS a seven out of ten.

Public Cloud

Amazon Web Services (AWS)

I am an end user of Amazon EKS. As a software engineer, we are using Amazon EKS as a platform for deploying our applications.

The most valuable features of Amazon EKS that I have found include scalability, simplicity in operations and management, and some great features for optimizing cost. Those are probably the main advantages.

Speaking about scalability, it basically means that we are able to scale our workloads according to our needs, which is useful. Regarding cost optimization, sometimes infrastructure in AWS might be a little bit expensive, so having some functionality to get it more manageable and to have some cost reduction solutions in place is always useful. Additionally, not only Amazon EKS but the Kubernetes platform itself is a very popular platform, and many developers are familiar with it, making it convenient for the company to use. It is much easier for our developers to get any information about solving problems and developing applications because information is widely available.

I have seen a positive impact from Amazon EKS for my organization since deployment; it provides a very robust and cost-effective platform for deploying our applications. The Kubernetes platform is well known and widely available, which means there is a lot of information about it. Since it is a manageable solution, it removes a lot of the burden and headache of managing our own cluster on bare-bone hardware. While we do not rely heavily on Amazon infrastructure, I understand that if someone were to rely on it heavily, it would be much easier to integrate with Amazon EKS.

In my opinion, Amazon EKS could improve its plugin management; while Amazon offers some improvements, they often come at an extra cost. Compared to Google, for example, having the same cluster in Google Cloud is much easier because it hides all the complexity of managing Kubernetes add-ons and plugins. EKS is improving in this area, but it could still be smoother and better. Upgrade management is also a constant concern because EKS frequently forces users to upgrade, which can be inconvenient due to the risks involved in introducing something new, especially at the platform level.

I have been working with Amazon EKS for probably two or three years.

It is hard to say how Amazon EKS's self-healing nodes help me minimize administrative burdens since we have not had any issues with them in a Kubernetes environment. The Kubernetes platform provides capabilities to replace nodes, and everything just goes smoothly under the hood.

We do not use Amazon EKS's automated patching feature for our Kubernetes clusters.

Amazon EKS's support for AWS tools integration has not influenced my application development and management process much; we do not rely on any specific AWS features.

I do not often communicate with Amazon EKS technical support and customer service.

I have reached out to Amazon EKS support a few times in my previous project where we had a subscription plan for support, but in the current project, we have no business support.

My impression of Amazon EKS support is generally positive; my experience depends on the person on the other side, but the vast majority of cases involved very professional and skilled engineers. However, there was one instance where I was not completely satisfied with the answers received. Overall, I would rate them eight out of ten.

Positive

Before Amazon EKS, we used a different solution, specifically ECS and Elastic Container Service, and we still use it alongside offerings from other cloud vendors such as Google, as well as self-hosted clusters.

I personally participated in the initial setup and deployment of Amazon EKS. The setup process for Amazon EKS is fully automated, as we use Terraform for bootstrapping and managing our infrastructure, so there are no issues at all. Everything was straightforward with no challenges. The only thing I can remember, which is relevant for the previous question, is that when creating a Kubernetes cluster in the AWS web console, it does some changes under the hood, such as creating a default role for authentication. However, doing it through command line tools or automation with Terraform requires some manual steps, which is not very convenient.

I would like to optimize the Amazon EKS setup process in the future, but we probably will not take action because creating a new cluster is a rare task for us. Spending an extra 15 minutes on manual steps probably would not be worth the effort of full automation.

I do not have any metrics to measure the impact of Amazon EKS on my organization's ability to manage complex workflows efficiently.

I am aware of the pricing of Amazon EKS. I do not consider Amazon EKS an affordable solution; it is not cheap for sure, but it depends. For a small project, such as a personal project or a proof of concept, the cost is fairly noticeable. However, for a full production setup, I think the cost is manageable.

The main advantage for us in choosing Amazon EKS is the AWS infrastructure and the cloud ecosystem, including databases and compute instances, which is probably even more important than Amazon EKS itself.

I have not utilized Amazon EKS's integration with IAM.

I do not really integrate Amazon EKS with other AWS services; our current application would work with any Kubernetes platform, whether it is Amazon EKS, Google Cloud, or any other self-hosted Kubernetes cluster, most likely with some minor tweaks.

We do not use any specific Amazon EKS APIs or functionality, so I do not have anything to share about integration capabilities.

My personal rating for Amazon EKS is six out of ten, as it really depends on personal preference.

Public Cloud

Amazon Web Services (AWS)

I use Amazon EKS for creating users, depending on the project I've worked on. I use it to update config maps and for role binding in the Kubernetes cluster. Additionally, I use it for creating namespaces and accessing different clusters, such as dev clusters.

Regarding integration with IAM in Amazon EKS, I use it primarily for creating IAM users and managing permissions for users.

While I cannot specify a single favorite feature in Amazon EKS, I particularly value the user creation and config map functionalities. Both processes are straightforward - creating users and updating the config map are easy tasks.

The main benefit of using Amazon EKS is that it makes work more efficient and enables faster delivery.

The main area for improvement in Amazon EKS relates to master node control. When setting up a Kubernetes cluster independently, you have access to the master, but with AWS, you do not have control over it.

The support team of Amazon EKS is excellent and very helpful. I have never experienced any issues with them.

Positive

We briefly used Google's solution before switching to Amazon EKS. After that brief period, we have exclusively used AWS.

For the initial setup of Amazon EKS, we typically follow established guidelines. In most cases, we are not responsible for creating it directly. We work through our Jira and Confluence systems, completing assigned tickets and projects rather than setting up the system from scratch.

The pricing of Amazon EKS varies depending on the size and specific requirements of individual companies or clients. Many companies choose AWS because of its competitive pricing. The prices are considered fair by most users.

On a scale of 1-10, I rate Amazon EKS a 9.

Amazon Web Services (AWS)