I usually work with AWS tools focused on infrastructure deployments, onboarding new customers to the cloud, and offering the best practices across infrastructure, networking, security, monitoring, and availability, discussing high availability solutions and implementing the best practices over these. That's mainly my scope. For the development part, when it comes to services such as functions, Lambda functions and X-Ray and development services, I actually interfere with them in the deployment part and not for the configuration or the development part.

I've built a tool that can manage all these resources, whether it's on Microsoft Azure or Amazon Web Services or Oracle itself. This tool is efficient when it comes to assessments, assessing the environments for customers, getting the best security practices and measurements across the environment the customer has, having a cost optimization component that can be used to optimize the cloud environment. It covers automated deployments that you use with a user interface, so you don't have to write any code while deploying complex scenarios.

Regarding my experience with Amazon EKS, I have a complete solution for deployment as well. The tool is really powerful and can be used to do various things. I'm involved in the infrastructure, networking, and deployment part, so deploying these resources is one of my daily responsibilities. I use this tool to deploy all of these.

The deployment process for Amazon EKS is straightforward; you don't have to do anything basically. You just have to get the right image and the normal operation for Amazon EKS.

The best features of Amazon EKS involve the orchestration, which may be the concerning part of each customer when it comes to Amazon EKS especially. The automation part, the deployment and monitoring part, the security as well, having the connectivity going private or public, or using Kubelet are various aspects that users should be aware of, providing good experience while discussing these options with customers.

The integration capabilities of Amazon EKS seem fine, but it can be challenging using AWS services compared to other cloud providers, for example, Microsoft Azure. From using both platforms, Microsoft Azure offers more simplicity while doing complex deployments. AWS offers the same solutions; however, it seems more complicated when it comes to independent resources, where you need to establish dependencies before doing the actual resource deployment. This part needs an automation layer that already exists with the Microsoft Azure portal, which facilitates everything for the user experience.

I don't see much room for improvement for Amazon EKS; the Kubernetes technology is the same across all cloud providers. Most customers focus on the main common features they will use, such as the monitoring or the orchestration part, which is their main concern when it comes to this service specifically.

I have experience using Amazon EKS for approximately six years.

Regarding technical support from Amazon, I never personally experienced it, but the team I'm handling has faced their support, and they indicated they're quite good, but not on the first level part.

Positive

I have definitely seen an ROI with Amazon EKS. I developed a tool for cost optimization that can cover all of these, even with better approaches than the cloud itself. The tool I developed uses the native AWS recommendations, so ROIs and any saving plans that can be offered are included within the cost optimization. However, we've added our experience component upon using these resources as well.

For example, AWS will never tell you that you have to delete a virtual machine or an EC2 instance. However, our report can detect the stopped instances and provide a recommendation for the customer that for cost saving, they can use a backup or snapshot for this machine, and delete it. If they need to restore it, they can do that, or they may have to remove it if they're not using it.

In terms of pricing for Amazon EKS, I think it's quite reasonable. If we compare the cost to other providers, with providers such as Oracle, it will be much higher in cost. When comparing it to Microsoft Azure, it seems similar, with some variations. On a scale of one to ten, I rate Amazon EKS a seven out of ten.

The main use cases for Amazon EKS included testing some POC concepts to see how Amazon EKS works. Additionally, we can use the Kubernetes service as a VM, and AWS provides Amazon EKS, which allows us to get directly connected nodes and all the VMs without having to provision additional VMs for Amazon EKS. This feature enables us to test how it works easily.

I have used self-healing nodes with Amazon EKS, and on one occasion, I mistakenly stopped the Amazon EKS cluster. While configuring the PVC on the nodes for the pods, the node went down, and the new pods were in a waiting period because there was no node available for pod scheduling. The automatic healing feature created a new node, as I had set the minimum node size to two. Since one node was unavailable, my pod could not schedule, but the auto healing created the second node automatically, which was the easiest part.

What I appreciate about Amazon EKS is the autoscaling feature. When you configure the Kubernetes cluster manually on the VMs and need to add new VMs or if you run out of storage for the VM, you don't have to worry about that with Amazon EKS. It automatically scales the nodes and provides another VM ready for you automatically, which is a great aspect of Amazon EKS.

The main benefit of using Amazon EKS is the automation for the cluster. When creating it manually, it takes a long time to set up the VMs and configure them as server, master, and worker nodes. With Amazon EKS, you can run just one command to configure the whole cluster with the desired number of nodes.

Regarding improvements for Amazon EKS, I am unable to specify anything at the moment because it has been a year since I used it, and some problems I faced might have been due to my mistakes.

I cannot specify improvements for Amazon EKS at the moment. However, I believe they could improve pricing, as I currently find Azure Kubernetes Service to be less expensive than Amazon EKS.

I have been working with Amazon EKS for around three to four months during my internship period before I joined this organization.

The initial deployment of Amazon EKS was straightforward, although I faced some challenges due to a lack of knowledge about the service. Once you fully understand the service, you won't encounter challenges or problems while deploying the cluster.

The integration part was not very challenging; I faced just a few configuration issues, and then we were good to proceed.

I have not utilized Amazon EKS's integration with IAM; I have just used it normally and did not use that feature much.

I have not integrated Amazon EKS with AWS services; however, I have hosted the cluster in Amazon EKS and used it with Jenkins and Argo CD, focusing on CI/CD pipelines and deployment.

I have not escalated many questions to AWS support, but I did raise a question regarding the cost because I was not aware of the total pricing for the cluster, which cost me around $100 or $150. I escalated this to AWS support, expressing my confusion about the pricing, and they waived the issue away as it happened by mistake.

Neutral

I have experience working with Kubernetes and the Azure AKS product.

I cannot recall all the key differences and both pros and cons of Amazon EKS compared to Azure AKS because it has been a long time since I used EKS. Currently, I am using Azure, so I cannot compare them at this moment. If you ask me about Azure separately, I can provide insights on it, but comparing both is difficult as I do not remember all the services offered by each platform.

The initial deployment of Amazon EKS was straightforward, although I faced some challenges due to a lack of knowledge about the service. Once you fully understand the service, you won't encounter challenges or problems while deploying the cluster.

I find the pricing for Amazon EKS to be quite expensive. The EKS service itself is free, but you will incur costs for the VMs used as nodes in that cluster. The pricing is similar to provisioning EC2 instances, which may be much higher than normal EC2 instances, but the automated provisioning is worth the cost.

In my opinion, they are pretty much the same.

Regarding your organization's social media presence, I inquired about a certificate that I can share on LinkedIn to show that I have participated in this review and reviewed some products.

I would rate the impact of Amazon EKS on the organization's ability to manage complex workflows as nine or ten out of ten.

For users evaluating Amazon EKS for their environment, I recommend gaining knowledge first about the service, as it becomes quite easy to use afterward.

The documentation for Amazon EKS is quite good; I do not see any areas needing improvement in the knowledge base.

I would rate Amazon EKS as a solution an eight out of ten. I am not completely aware of the service and have not explored all the parts, which may affect my rating. I might be wrong at that part, but I give it an eight due to my self-doubt regarding not using the service in all aspects.

I decided to go with AWS because during my graduation, we had a course on AWS in our extracurricular activities, which sparked my interest in it. Additionally, during my internship, there was a need for a Kubernetes cluster, which led me to land in the Amazon EKS service.

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.

I use this to develop my products. I use it internally in my company and in the other projects I have been working on for the deployment and managing the services which I'm deploying into the Amazon EKS infrastructure. I have not actually been involved with automated patching, as my role has predominantly been as a developer setting up how we deploy our applications into Kubernetes. That's primarily where I've gained experience, not on the server management side where the patching is done, so I'm not sure how the patching works or what benefits it could offer in that context. However, I can discuss how I manage my CI/CD pipelines, application deployment, and how I use Amazon EKS for deployment. That is the part I have experience with.

I have been using Amazon EKS, and I started with ECS first, which is the Elastic Container Service where I can deploy my workloads. ECS is also one of other managed services from AWS, but it is not supporting Kubernetes. We wanted a platform where we could have an orchestration platform for Kubernetes. Hosting our own Kubernetes server is a very tedious job. Kubernetes itself is a very complex tool to manage and requires a lot of resources and knowledge to build a working solution. That's where Amazon EKS comes into the picture as a managed service built on top of a Kubernetes engine, offering many tools, such as CLI integrated tools or through their console to quickly set up a Kubernetes cluster, which otherwise is a tedious job.

With that offering, it is very easy to set up the Kubernetes cluster in Amazon EKS, and it is very easy to manage the nodes we have there, such as what instances we need. Since it's an AWS offering, we select a variety of EC2 instances available, and it integrates with it nicely. The same applies to the infrastructure as a service tool, IaaS, such as Terraform. It is very easy to create and manage Amazon EKS clusters through Terraform. Overall, it offers a lot of tooling and saves a lot of time compared to setting up and managing a Kubernetes server ourselves.

A specific feature of Amazon EKS is that Kubernetes is open source, and all its capabilities are based on that. The main advantage is launching and managing a Kubernetes server becomes very easy, as I receive out-of-the-box support for other AWS service integrations with Amazon EKS. For example, services such as AWS IAM directly integrate whenever I want to set up access control or security measures on my Kubernetes server. EC2 offers out-of-the-box support when setting up Kubernetes nodes. All this setup we need to do otherwise becomes much easier with Amazon EKS.

Regarding measuring the impact of Amazon EKS on my organization's ability to manage complex workflows effectively, there are measurable metrics we use. Whenever we set up any project, it is crucial to ensure we understand the availability and scalability of our applications. When I set up any application, I look at how we will be able to scale whenever there is a requirement for higher loads. To measure the Amazon EKS platform's effectiveness in this regard, I evaluate the different methods available for scaling the application. For instance, based on CPU and memory consumption, I can scale or use scalability tools such as KEDA. KEDA helps us scale based on various factors, such as the number of requests my application receives or the load on my service based on metrics. These tools can be easily installed on my Amazon EKS server without restrictions. Availability is crucial when setting up a Kubernetes cluster, especially when designing for a global audience using Amazon AWS. The options to configure multi-region and multi-AZ setups are incredibly valuable, as these features ensure high availability without complex traditional setups required for on-premise hosting.

One area I observed during setup was that while managing it through CLI and Terraform, there are many possibilities for setup and infrastructure updates. However, I believe the console experience could improve. In the AWS console, when trying to set up an Amazon EKS cluster, there were limitations on certain features I encountered a few months back while checking. EKS frequently updates, so I don't know if there's a new release. However, I found some features that I could not manage through the console, requiring me to use CLI or Terraform. It would be beneficial if we could have all features supported through the console, providing full management capabilities there.

I have been working with this tool for around two years now.

My current organization has not been using self-healing nodes, but I have used it in some earlier projects and organizations I worked with. When we decided to move away from containerization services such as ECS, we wanted a better orchestration platform that could easily handle those requirements. Kubernetes comes with many features for scalability, which otherwise we would have to manage ourselves with scripts. While Kubernetes is a good choice, it comes with its own learning curve, and understanding all the details is a big task. Services such as Amazon EKS, or maybe GKE for Google, provide the confidence that we will benefit from the orchestration framework that Kubernetes offers while also setting it up and managing it easily. We gain all the advantages that Kubernetes has as an engine without having to invest a great deal of time learning and configuring everything thanks to managed services such as Amazon EKS.

Regarding technical support, I recall one instance with Amazon EKS. I faced an issue with configuring pods in EKS that required access to other AWS services, such as IAM roles or S3 buckets. The setup was through OIDC providers in EKS, which set up trust relationships with IAM roles. There was a problem with OIDC provider setup a few years back when EKS was newer. I reached out, and I received good support when I submitted a ticket for the issues with the OIDC provider. They helped resolve the issues related to the trust relationship, identifying mistakes that needed fixing.

Positive

In my current company, I don't use it, but in my earlier company, we started with ECS, another AWS offering where we deployed our containers. However, as our deployment expanded, the limitations in scalability prompted us to explore better options. We began to reach a point where more than 30 or 40 instances of our services were running, and there was a need to support these across different regions. ECS offered some level of scalability, but it was not as customizable as Kubernetes, so we decided to transition from ECS to Amazon EKS to harness its full capabilities.

Using Amazon EKS as a cluster is free. The pricing only applies when I add the instances and set up nodes. For instance, when I add memory-optimized nodes, the applicable AWS pricing for those instances comes into play. Essentially, the pricing revolves around the nodes added, not the other configurations I'm attempting to set up.

Regarding the pricing of nodes, I find that it generally offers good value. I'm not certain what the comparative costs look against other platforms, such as OCI from Oracle that is known to offer lower pricing, but it ultimately depends. For example, AWS has recently introduced Graviton-based servers, which claim to be cost-saving, although I haven't used them myself. AWS provides several options, allowing me to choose configurations that suit my needs regarding CPU and memory. While I don't have firm details about enterprise pricing options or upfront reservations that may provide discounts, what I appreciate is the flexibility in selecting from various instance categories to meet specific requirements.

Based on my experience with Amazon EKS support, I would rate it a nine out of ten overall.

The main reasons for using Amazon EKS in our use were third-party solutions that were distributed as Helm charts. We were using Rancher to manage multi-cloud deployment for unification. We are also using it for evaluation purposes, building customer pilots and prototypes. Sometimes it is easy to make the build chain run through and come out as images and deploy them into Kubernetes.

It completely depends on use case. If you have got a very dynamic or a requirement to scale very fast with nodes, then Amazon EKS is a very good choice because you have got that reach and the ability to scale quickly. But if you have got a fairly static load, it becomes quite expensive quite quickly. They are expensive CPU cycles.

The main benefit of Amazon EKS is its rapid deployment. The fact that we can deploy it very quickly with infrastructure as code and then tear it down again when we are finished.

There is no real advantage to us from Amazon EKS because the advantage is the fact that we have a unified management product so we can deploy concurrently into multiple clouds and on-prem out of one pane of glass. That is the key thing there. As far as the development and presentation, sometimes it is easy just to load it up through kube control, sometimes you put it through a GUI control in front.

We have not been using it from the point of the application using the IAM. We have been using it because quite often our customers are tied back to usually Entra ID and things like that.

The only concerns I had with Amazon EKS were related to cost, the usual problem you have with cloud. It is fine if you can exploit it for dynamic loads, bring it up, get rid of it again. That is where its strength is. You pay for that premium, but as far as running the thing under constant load, it is a very expensive way of deploying.

In the early days, there were a couple of vulnerabilities exploited from the single control plane per region. So there is nothing stopping me deploying multi-region, and that means multiple control planes. So I could deal with that, the infrastructure handled the criticality. The only thing that I could possibly run into a problem with, which I have not had to at this point, but architecturally, is with regulated technologies, banks, that sort of stuff where you cannot be single provider sensitive.

We have been dealing with it from the beginning almost, since 2019.

Only in the past I think it had issues. The fact that regions only had a single control plane left a little bit of vulnerability in there, certainly in the early days, but I do not think that matters now. They seem to have solved that.

I had no problem. It was stable. Very stable.

It was very easy to scale.

The current stuff I am working with has been Kubernetes and building out operational software using Kubernetes. I was actually reviewing Nutanix as an option for some of the stuff I was building out.

Mainly on-prem, we are doing production work with a number of customers. We support them, we run an operational arm as well. I have been involved in platforming on Kubernetes, but we happily support any variant. We are cloud agnostic. So these distributions, we would use Amazon EKS or AKS, but not for long.

The driver in Rancher, as long as I do not have anything extremely different or complex, works completely the same whether I am driving the application onto Amazon EKS or onto a local on-prem.

We have not been using the automated patching. If we were in anger, we do not run the stuff long enough in Amazon EKS at the moment. Really, it is just up in demo and then torn down again. A lot of the stuff is being driven from other automation anyway, more infrastructure as code stuff. So that actually just gets driven completely in there.

I think that Amazon, every other provider, is adapting to the changes in the market now because the major cloud benefits are now fully saturated. Nobody else is going in for those benefits. They are starting to hit the reality of regulated technologies that are high value cannot be under a single provider. So a single cloud provider is not sufficient to support critical industry anymore. You have to have either multiple cloud or hybrid just to meet regulation in the future. So that constrains some of the flexibility. But the clouds are all working towards more on-prem extension, that sort of thing to make it more feasible.

I would rate Amazon EKS a six out of ten. I have a particular penchant for not actually overscoring anymore because of the way that people use this stuff. In other words, I consider adequate doing what it says they claim it to do. So that is a five or a six as they did what they said they would do. There is nothing wrong with that. It is what we agreed. I paid for it, they delivered it. I am satisfied.

For the usual use cases of Amazon EKS, we have been running different kinds of servers, such as web pages, and we have also used it to provide the SaaS solution for the end customer, delivering software as a service to the end customers. Basically, I deal with apps, SaaS applications, and websites.

We don't use Amazon EKS internally for us; we usually provide the service to others for their solutions.

The most valuable capability of Amazon EKS is managing the management portion of Kubernetes, which is the best thing that we get from Amazon EKS. Even though we have to upgrade it every six to seven months, it provides all the things required for us, so if a person knows how to install it and make use of it, that's all that's needed for using Amazon EKS.

Regarding self-healing nodes of EKS in minimizing administrative burdens for my customers, I appreciate that this feature allows nodes to try to heal themselves, which is a good feature. However, I haven't used this feature often, but having the service's ability to find and heal themselves or replicate is a good option for Amazon EKS to maintain high infrastructure uptime.

The area of Amazon EKS that could be improved is the development cycles because every six months a new version of Kubernetes is launched. Working in the infrastructure, I have found it quite difficult to keep up with infrastructure updates and new versions. Migrating the whole infrastructure from one Amazon EKS cluster to another is quite cumbersome, so if possible, version management should be made much easier than it is now, perhaps with some option to deploy code using blue-green updates. Creating a clone of the current infrastructure, updating it to the latest version, and terminating the old infrastructure would be a great enhancement.

I haven't used Amazon EKS's automated patching feature, but I believe it involves directly upgrading the AMI versions remotely or from the Amazon EKS dashboard. I understand it is a good feature, but I haven't used it yet.

I have been working with Amazon EKS for seven years in Kubernetes only, and I would say four years in Amazon EKS specifically.

My experience with the deployment and initial setup of Amazon EKS is usually straightforward. If you have the right Terraform code or the right knowledge, you can create it from the console or using Terraform or other tools; I don't find difficulties in starting a Kubernetes cluster. However, using the right principles or tools together with Amazon EKS may be challenging.

In terms of stability, Amazon EKS is pretty good. I don't encounter issues with stability if I use the right methods of deployment. For instance, using spot instances that are inexpensive can lead to downtime if not managed correctly.

My experience with customer service and technical support of AWS for Amazon EKS has been generally positive. Earlier, I was in developer support where the response time was maybe three to four hours after ticket submission, but I was able to resolve most problems with their support. I don't have any complaints.

I would rate technical support for Amazon EKS at an eight out of ten based on my experience with the developer support.

Positive

I have been using Amazon EKS for four years. In addition, I have used other solutions.

The integration of Amazon EKS with IAM is easy; if you have the right policy in place, you can create a role from the policy and then apply it to the application that you are using. It provides a way to use IAM to provision the software and infrastructure portions, as well as integrating application users into AWS IAM, making it very easy to implement if you know how to do it.

The influence of EKS's integration with other AWS tools on application development and management processes is significant; EKS itself is just the infrastructure. Application development requires the right tools with Amazon EKS, as it only provides a place to deploy things, and not the entire development cycle or management of workstations and servers. You must use something on top of Amazon EKS to fulfill the development cycle or CI/CD pipeline. Once the CI/CD pipeline is developed with Amazon EKS as the deployment platform, it becomes easy for developers to develop and test applications in the cluster.

I am not exactly sure about the pricing of Amazon EKS, but I think it is priced at the instance level, meaning EKS itself is not that high in price. However, whatever instances are used for Amazon EKS will determine the actual costs, particularly the traffic coming into the cluster.

Currently, I am not working with any software other than Amazon EKS, but we have plans to utilize some other applications, not just Amazon EKS, involving other services of AWS.

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

I am using Amazon EKS as an integrator.

Regarding Amazon EKS integration with IAM, I do not use it.

To use Amazon EKS as a cloud provider and as a Kubernetes cluster managed by a cloud provider, it offers more benefits because you don't have to configure the cluster on your own. You can use the default configuration and just set the right networking space, set the subnet, and a few other things, but you don't have to raise up or configure your own cluster.

Self-healing nodes help to minimize administrative burdens in the organization. It helps to keep the nodes up and running. Then you can use other solutions to minimize costs or to keep the nodes running most of the time.

You can use Amazon EKS to raise up clusters and deploy applications in the cluster. The cluster is managed by Amazon, so you don't have to configure it. You can use the basic configuration of Amazon, and you don't have to interact with etcd or with the Kubernetes most inner parts. It's more simple to use.

Amazon EKS can give you more flexibility to configure on their own. In general, it's a good product. There are many different products that can fit the needs of the user or the customer in every part of AWS. In Amazon EKS, they can give a class that can be more configurable from the user or expert user rather than just using the default EKS.

Amazon EKS support for AWS tools integration has an impact on application development and management because everything is deployed on the cluster. You have to debug the various pods in Kubernetes. There isn't a direct impact, but there is an impact because everything you deploy through the pipelines goes to the cluster and there you have to integrate the cycle.

The main problem or area for improvement is flexibility in configuration. This is the only concerning part and nothing apart from this.

I have been using solutions similar to Amazon EKS from other vendors. I used GKE from Google, the cluster of Azure, and I also used KMinikube. Of course, it's not the same thing, but in general, it can be compared. For testing, K3s are just different distributions. In general, I have used other cloud providers.

It's quite easy to install Amazon EKS.

In Amazon EKS, I see it as a stable product. I don't see any particular issues in terms of nodes or performance.

I believe Amazon EKS is scalable.

I have never used the technical support from AWS.

Neutral

I see return on investment with Amazon EKS. You can save in terms of time because you can raise up a cluster or more nodes, and you can raise up the storage of the particular node in a few minutes. You don't have to take care of managing the machines directly. There is significant time-saving. You don't have to take care of the rack system because AWS has a team that works that part. You have just to pay. In terms of price saving and money saving, it depends on everything, but in general, you're going to save money.

In general, the price of Amazon EKS is expensive, but it depends a lot on the user knowledge of the tool and how we can manage the cost, which solution offers better, which solutions they can use to reduce the cost. For example, the different VM types, the Preemptible VMs or the Preemptible nodes, or you can pay one time for the use, you can reserve the machines. There are many different ways to reduce the cost.

I see big differences between Amazon EKS and GKE. The way you install the cluster is different. In GKE, when you install the cluster, it raises the nodes for you. In AWS, you can install the cluster and then you have to raise up the node using Auto Scaling Group or whatever. It's more integrated maybe. Also in terms of documentation, Google is different from Amazon.

Regarding the automated patching feature for Kubernetes clusters in Amazon EKS, I don't know any patching feature.

On a scale from one to ten, I rate Amazon EKS an eight.

There are migration projects where we need to migrate some on-premise services to Kubernetes. In that case, we have used Amazon EKS to migrate our workload. There are two production services that we need to deploy on the cloud, so we chose to use Amazon EKS to deploy them on the servers.

There are multiple node clusters that we have within Amazon EKS. We have different node groups that we have used. Some of them are high performance, some have high-speed hard disks, and some have high CPU. There are multiple node groups that we have provisioned and also enable the scaling within the pod level and within the cluster level. There are multiple features that we have used along with node management.

For streamline, we need to apply GitOps within Amazon EKS. Whenever there is a commit in the deployment-related stuff, we need to deploy the new image on the image repository, and from there, we need to update the kubectl YAML files with the new image tag. We can also choose the Helm charts based, and we can also choose Argo CD for the automated deployments.

We have implemented two things with Amazon EKS. First of all, OIDC-based connectivity between the AWS services to the Kubernetes workload. Additionally, we implemented RBAC. We have used RBAC to provision IAM users to have proper security and a constrained environment so that read-only users can only read the things.

We have used Amazon EKS Anywhere for on-premises deployments, and within Amazon EKS, it has an air-gapped environment where we can deploy the things and manage the local type of Kubernetes.

Managing the production workload in Amazon EKS is highly valuable. It has many features, for example, self-healing, automatic deployment, rollouts, and better management. It is an Amazon managed service, so we need to just focus on the cloud itself.

We have installed Prometheus and Grafana within our Amazon EKS, and we have used DataDog operators as well to have proper production workload management and monitoring management system. We can see the logs, alerts, and everything related to it. We have integrated Slack and email addresses through SES. This is how we are monitoring our production workloads and get alerts based on problems within our production.

The main benefits from using Amazon EKS include it being a well-tested product that we can use to deploy our workload. Its management system is very efficient. We can deploy things very easily and resolve our issues efficiently. It has deep AWS integration and a managed control plane. It has built-in IRSA-based security model for IAM roles. We have flexibility and portability. We can use Helm, Argo CD, Flux CD, Istio, and Linkerd. We can use multiple EC2 machines, such as spot instances and Graviton-based instances that are GPU-powered. These features help us use Amazon EKS for our production environments.

I would appreciate seeing integration between the other services in Amazon EKS. For example, there are now more managed Prometheus and managed Grafana services available last year. I would appreciate knowing more about how AI-based services get integrated with Amazon EKS and what kind of AI automation, healing, or troubleshooting services Amazon will introduce in upcoming releases.

I have been working with Amazon EKS for three to four years.

The setup of the Amazon EKS environment is quite fairly simple, and we can easily automate them using Terraform as well.

Once everything is set and done, there is no maintenance required, which is a very good point.

I did not see any crashes, downtime, or performance issues with Amazon EKS.

We have enabled the cluster-level enablement and auto-scaling in Amazon EKS, and that helped us significantly. Whenever we have peak time, it will automatically manage the node for us, and there are more nodes to manage our workload.

For a few of the cluster upgrades that got stuck, we connect with Amazon tech support, as we have business support with Amazon. We connect with them, and we figure out the problem. They help us to troubleshoot the issue, and we run commands related to Cordon or Taint. With this, we complete our upgrades process.

On a scale of one to 10, I would rate the technical support and customer service of AWS as eight to nine. They are very technical, and they can easily fix things within 20 to 30 minutes.

Positive

I worked with on-premise Kubernetes, and I also worked with Azure Kubernetes, AKS.

I have worked extensively with Amazon EKS, and I have automation scripts ready. Whenever a new client comes to me, I request them to see my previous portfolio, and I show them my Amazon EKS work and how quickly I can set up their Amazon EKS and run the CI/CD so that their workload can get migrated to Amazon EKS. It is quite easy for me now to advocate for Amazon EKS.

We have a big business up and running in Amazon, and we have different AWS accounts: dev, test, and prod. Based on that, there is a root account who is paying the prices for us. The workload and the profit that we are getting, we are satisfied with what it is offering.

The pricing of Amazon EKS depends upon the node group that we are choosing and what kind of auto-scaling that we have implemented. It is totally dependent on those things, including what kind of network bandwidth that we are consuming.

I find the pricing of Amazon EKS reasonable. We actually are going to pay a yearly advanced payment, which helps us save on cost.

Amazon EKS has strong integration with its services. In Azure Kubernetes, it does not have strong, deep integration with its services, for example, Active Directory, Azure Registry, Azure Monitor. Both have their managed control plane and node management. Amazon EKS has a different pricing model - it is per cluster control plane level, whereas AKS is not on the control plane fleet's history. Regarding security, Amazon EKS provides IRSA-based, IAM role-based security, whereas AKS provides directory, Azure Active Directory.

It is a very well-known product, and there are many clients in the market who are using Amazon EKS, so it is the best service offered from AWS. I rate it a nine out of ten.

At the moment, whatever is required in Amazon EKS is already there.

As integrators, we are the user of Amazon EKS. Our customer's main use cases for Amazon EKS are mostly internal services automation and development and deployment automation, which we are using for the digital applications of our customers in the AWS cloud.

The most valuable features in Amazon EKS include a suite of different services, such as code versioning, pipelining, code deployment, and code quality checks; we are using the total suite of the Amazon EKS.

From a project management standpoint, the automated node provisioning feature in Amazon EKS helps to streamline the application deployment process because the benefit I see with this product is that our deployment turnaround time reduces considerably, and all compliance standards are met. Code quality is maintained, and there are specific indicators designed in the product to identify quality issues with minimal effort. The Agile mode of project execution methodologies can also be implemented due to the code version controls and pipelining controls.

Most importantly, the deployment side of code releases and release management features are maintained without major hassles, within a short span of time, and without delays to customer experience. From both operational management and project management angles, these tools address human as well as programming side hurdles, eliminating most gaps and enabling timely project execution without surprises and ensuring quick turnaround time while meeting delivery deadlines.

Amazon EKS's deep integration with AWS services such as Identity Access Management impacts the approach to security and compliance because it integrates with IAM authentication and the multi-factor authentication process, allowing access only to those who need it.

I recommend that Amazon EKS could be improved by integrating AI intelligence with its components because EKS or the Kubernetes cluster has not yet undergone an AI wrapper. An AI component integrated into Amazon EKS, such as failure analysis and intelligent recommendations when failures happen, would be very helpful. Although automation is present, this AI feature would enhance the overall capability.

I have been working with Amazon EKS for almost four or five years now.

I have not faced any challenges with Amazon EKS; it's good and quicker. Initially, implementation can be a bit time-consuming, but once set, it becomes a 'code it and forget it' sort of environment.

I have no complaints about the stability of Amazon EKS; it is good, with no concerns at this point in time.

Amazon EKS is good regarding scalability; it suits conventional services and has room for improvement with upcoming agentic AI and GenAI resources.

My experience with Amazon support is good; we always had a good association with them, so no concerns on that. I would rate the support of Amazon EKS above seven.

Positive

Customers have seen a return on investment with Amazon EKS because they are happy and see value in the services; however, as the volume grows, the OpEx cost also increases, so any respite on OpEx cost for customers with exponentially growing volumes would be helpful.

Regarding the cost of Amazon EKS, I would say it's relative to the organization based on release management processes; for big organizations where customer experience matters, such as in the retail segment, the cost can be very high due to numerous daily changes. For companies in telecom and retail, as Amazon is a pay-per-use service, our usage levels are high, so I would desire if Amazon could provide certain discounts or credits for customers who utilize a lot of resources.

Our customers use the solution on the Amazon AWS cloud. They purchase Amazon EKS through AWS only.

For those looking into using Amazon EKS, my advice is that it is a good product, although the downside is that if the volume grows, the OpEx cost increases significantly. I would strongly recommend it for small and medium companies. For big companies with more releases, it also attracts more OpEx costs, so if there is a mechanism to control costs, it can be suitable for everybody.

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

From AWS, I use many services, but mostly my work revolves around Cloud Native, specifically Amazon EKS. Kubernetes is my area of focus and expertise. Most of my expertise is around Kubernetes and Cloud Native technologies. This is why I don't call myself a full cloud offering expert, but I mostly focus on the Kubernetes usage with other OSS solutions around K8S. It's not really a niche; it's huge.

I handle both application workloads and data ingestion workloads.

Based on my experience, the best features are backed up with extensive security that AWS allows and EKS is firmly integrated into their entire AWS cloud offering. The second feature is the ability to do what we call an in-place upgrade (upgrading an existing cluster), which is a very strong capability. Additionally, the ability to integrate other add-ons such as service mesh exists, but I don't use it heavily. The ability to use all EC2 node options, including GPU options, works quite efficiently.

The freshness of the Kubernetes versions is the most interesting aspect around CSP's Kubernetes offering; it's about how close they are to the latest and greatest of Kubernetes. GCP is the leaders in that area, but Amazon is quite close behind, which is very important.

It is definitely helpful to streamline the application deployment process.

Regarding the flexibility part, if I want to use something such as Kong/Linkerd service mesh or other solutions, most of the CSPs bind you to their own solutions rather than allow other options to be made and integrated with, and this is what I mostly miss in their part.

In terms of built-in observability in Amazon EKS, I know it's mostly about the great integration with AWS itself. When I want to integrate it with any Grafana or Prometheus solution within AWS, things work efficiently with IAM. However, when I want to cross the boundary of the CSP, that becomes an issue. Integrating some open-source solutions works, but I need to work really hard for that.

The major area for improvement I've seen involves deep diving into one CSP with no equivalent solution elsewhere. The most important consideration is about the pricing and the flexibility of moving and building a multi-cloud environment for most customers. The issue is that when CSPs try to lock you in, flexibility becomes the most critical aspect.

Amazon aims to put you in a very Amazon-centric environment, but you need to be aware when you're using Amazon EKS that you're not locked in. The major paradigm for customers with maturity in using cloud solutions  is to avoid vendor lock-in. Most early adopters understand this, but the main mass, such as the banking companies I work with, aren't in the same state of mind; they need to build everything from a Cloud Native perspective with as much OSS as possible.

I am still using all these technologies.

I would rate stability as nine out of ten.

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

For technical support with a business plan, I would rate it as nine out of ten.

If support is not paid, I would rate it as six out of ten.

This difference is mainly because of the response time.

With business support, I rate the solution overall as nine out of ten.

Positive

Considering the pricing of the product, I think it's affordable because it's mostly about EC2 stuff, and the control plane is not too expensive, taking into account what they do behind the scenes. Managing my own stuff in an on-prem environment helps me say that it's quite inexpensive in that aspect. The control plane is cheap, but the pricing of EC2 remains the same. I mostly don't prefer using EKS Fargate - managed containerized environment because it makes the devops team dumber and allows vendor locked in; it prevents me from managing my own infrastructure - scaling and fine tuning of resources' usage. Using margate as Autopilot in GCP and other products makes me more inclined to be locked in since it provides many features without the need to think much, but eventually, that's how the CSP will lock you in.

The integrations with IAM and Elastic Load Balancing are fundamental aspects. EC2 is the most important integration, and IAM is very strong in Amazon EKS, stronger than in other clouds. However, I need to compare it regularly as this landscape changes daily. The ELB and all the load balancing capabilities are quite strong in Amazon architecture and Amazon EKS architecture as well, so it integrates efficiently. I miss the flexibility to use other options, but I understand why they integrated it so tightly into their platform.

This isn't only an Amazon issue; it also occurs on GCP and other platforms, including Azure.

Overall rating: 9 out of 10.