I use Amazon EKS for one of my customers when I am an independent contractor. They do video recording for events such as weddings, advertisements, and other occasions. They wanted to stream their content, and I advised them to use Amazon EKS as a good solution so they can easily ingest the raw materials, process it, do all the cuts using specific video software, and then publish it wherever they need.

The ease of implementation and integration was accomplished by writing some small scripts. I implemented workflows for data ingestion, sending it for cuts, and then directing it to the presentation layer. The simplicity of it was key.

The automated patching feature for the Kubernetes clusters provided valuable benefits through ease of maintenance and simplification of maintenance. I don't have to manually monitor or create any additional services for monitoring the patches; it's just there and does the work automatically.

From my perspective, integrating existing applications into a single workflow is beneficial for application development and application integration.

The workflows were straightforward, collecting data from raw recordings from cameras, putting them on cloud storage, ingesting them into video editing software, and going to a CDN for publishing.

About a year and a half ago, the cost was somewhat high. Though I wasn't directly affected as my customer paid for it, they complained about the billing. If they could reduce the price, that would probably attract more customers, especially from this industry, as they are rather small companies with limited budgets for such tooling.

I have been working with Amazon EKS for about a year and a half, with my first notes dating from March 2024.

I escalated a couple of cases to AWS support. I have mixed feelings about this as they were quite helpful, but the response times were quite long. It took them about five business days to get a response to my question, but when they replied, the response was very valuable and helped me.

I didn't notice any crashes, slowness, or performance issues with the Amazon EKS product. My client could have potentially experienced such issues while using it, but they never reported any complaints, so I don't believe there were any issues.

I would rate the tech support around seven or eight on a scale of one to ten.

Positive

I worked with container services about a year ago as part of my project at that time. I enjoyed using AKS, but I think its equivalent in AWS is better; it's more mature and easier to implement than AKS on Azure.

The best feature I found in Amazon EKS is ease of implementation. I'm not very knowledgeable about video software and had to learn it quickly for this specific project, and I found it very easy to implement. It probably took me a couple of hours to really understand it and learn how to use videos, and it was probably the easiest of all the solutions that I tried.

I use the DevOps server as software as a service on Azure. I didn't need to set any server for that; it was just there. I added it to my dashboard and started using it.

In terms of cost savings, time savings, and efficiency improvements, I've definitely seen returns on investment. Considering my rate and the couple of hours spent, rough calculations show around 30% return on investment.

The majority of my time setup cost was very affordable, taking just two hours. It was easy as I didn't have to worry about setting all the infrastructure underneath, just using what's there. This saved my time, allowing me to complete the project within several hours instead of days or weeks.

When I evaluated several solutions, Amazon EKS looked more intuitive to learn. I was prototyping for two hours each, and with Amazon EKS, I had this raw prototype running after around two hours. With other services, after two or three hours, I was still in the middle of my work with no visible effect, so that was the benefit.

I am working with a set of tools within the Azure toolbox. Azure is a huge collection of services with over 100 of them. I use virtual machines, Azure Functions for serverless processing, especially for creating APIs that do automated tasks. Additionally, I use SQL Server database and infrastructure as code, creating using Terraform, creating virtual private networks, setting up firewall rules to increase the security of my customer's solution.

I give Amazon EKS a rating of 8 out of 10.

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.

We use Amazon EKS for hosting our policy admin system, and it has its own benefits. The scalability aspect of it is what we considered Amazon EKS for. It is a managed service, so we don't need to take care of the underlying operating system and other things. It was one of the preferred services in AWS which we chose.

The benefits I have experienced with using the automated patching feature are key, because considering that this is a managed service, we want to be more focused on our application rather than doing all these upgrades, especially given the amount of upgrades at each of these microservices level applications. We don't want to worry about that, and there is always this blue and green setup which we can have where, if there are any issues, I should be able to switch over to my blue whenever there is a deployment. Those aspects have helped us.

What I appreciate best about Amazon EKS is the managed service part of it because we don't need to worry about the underlying operating systems or the upgrades we need to have. The flexibility at which we can spin up multiple pods in each of the Kubernetes service and the service availability aspect of it are the key points.

I have used the integration with IAM; we used IAM roles, focusing on security aspects. We had multiple IAM roles and policies defined so that it is quite secure.

A few improvements I can think of for Amazon EKS would be on the monitoring side; they have very good monitoring aspects of it, but it has its pros and cons. Having some access and visibility into their Amazon EKS services and setup would be good because there are instances where some of the pods crash, but we don't have detailed monitoring available since once the pod crashes, we can't get enough logs. If they can have a backdoor or backup capability, whenever a pod is not able to serve, to get all the metrics before killing it, that would help us investigate the reasoning behind it more thoroughly. I think that side of it is missing.

Regarding Amazon EKS pricing, they have corporate level discounts, but one key aspect is the pros and cons. One immediate deploy capability is that I can trigger a pipeline to get an Amazon EKS setup done and start using it, which is much more efficient in the short term. However, in the long run, the scenarios we've seen indicate that it requires integration with other services, and the network egress charges are a bit higher. The intent of starting with reduced costs using Amazon EKS doesn't hold as clearly when we consider it for the long run; we start with a low cost and then realize it doesn't justify that.

I have been using Amazon EKS for almost five years.

The support for AWS tools, such as integration, has significantly influenced our management. Considering that we are a big corporate with direct connects with the AWS solution architect and other people we work with, it's as simple as raising that support request and they will be here. I think we even had the highest level of support we can get from AWS with respect to this.

I think very highly of Amazon's support team; they are really good, especially considering that we have the highest level of support and their support management team is also involved in calls to give any kind of priority to our requests.

Positive

I would recommend Amazon EKS to other people, but it depends on the scenario. Kubernetes for sure, but I suggest going for Amazon EKS if yours is a smaller enterprise. If your load is too high and fluctuating, then it makes sense to try Amazon EKS, learn how Kubernetes works for your organization, and evaluate the cost-benefit analysis. If you are considering it for a longer run, I recommend conducting a cost analysis to see if moving to a local on-prem system could be more beneficial. It truly depends on the case scenario, so it's important to do the cost analysis as well. On a scale of one to ten, I rate Amazon EKS an eight.

I describe my use cases as being for web applications and for API applications.

Simplified application deployments and infrastructure management

What I find best about Amazon EKS is its simplicity and that I don't need to care about control plane. IAM authentication has been a great feature, and with the latest changes, we don't need AWS ConfigMap.

The benefits I have seen from using it include simplified Terraform code, and the fact that we don't need to configure OIDC anymore. Additionally, we don't need to manage ConfigMap.

I don't know how Amazon EKS can be improved; it's ideal already.

I have been using it for five years, since 2020.

I don't remember any issues at all regarding stability.

The scalability is great with Carpenter; however, I don't know about the scalability of control plane, but worker nodes scalability with Carpenter is great.

I have used their support team from Amazon a few times, and it was good, as I remember.

Positive

I did not previously use a different solution.

The initial setup was not complex.

The pricing is cheap, around two USD per day for one cluster, and I think it's a good price.

AWS ECS

I have used Amazon EKS integration with IAM.

I can't remember any challenges while using it, maybe in past years, but not now.

On a scale of 1 to 10, I would give Amazon EKS a rating of 9.

I would definitely recommend it to other people.

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.

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.