Amazon EKS Reviews

I'm actually working for a company that uses AWS as a cloud platform, and for our clients, we use Amazon EKS. We utilize multiple clusters and other requirements, making Amazon EKS our choice for deployment service or orchestration service.

The usual use case for Amazon EKS is to deploy an application intended for heavy user load and traffic. In technical terms, there are multiple services to choose from, but we choose Amazon EKS for its orchestration, load balancing, and auto-scaling capabilities. With this service, you don't have to worry about manual auto-scaling or manual load balancing. Before Kubernetes, manual intervention was needed for scaling applications, leading to potential crashes if capacity was exceeded. Amazon EKS alleviates those concerns with its auto-scaling feature, where predefined thresholds automatically trigger the launching of additional resources to handle increased traffic. Also, Amazon EKS allows configurations such as minimum and maximum server requirements, ensuring scalability while minimizing costs.

The features of Amazon EKS that I find most valuable include load balancing, auto-scaling, networking, security, and scalability.

Scalability in Amazon EKS refers to the ability to automatically scale up or down your application based on traffic needs. For instance, if you initially expect 10 users but suddenly have 20, Amazon EKS automatically handles the scaling, thereby preventing application crashes and maintaining service availability.

Reliability is crucial when running an application on Amazon EKS, as it ensures your application never crashes. With Amazon EKS, you don't manage the infrastructure yourself; Amazon takes care of it all. You simply need to deploy your container, select the required configurations, and Amazon EKS handles the rest without requiring you to manage the underlying resources.

I have utilized Amazon EKS's integration with IAM, which stands for identity and access management. IAM restricts access to services, ensuring only authorized personnel can access certain capabilities. This prevents mistakes or unauthorized actions, maintaining security throughout the platform.

The support for AWS tools integration in Amazon EKS influences our application development and management significantly. With integrated features related to security, scalability, and billing, we ensure the efficiency of our processes. At my company, we manage around 600 clusters on Kubernetes and emphasize reliability by integrating Amazon EKS with various third-party applications. This integration aids in deployment, security, and ultimately, efficiency, as it ensures that applications remain available and perform efficiently.

One area of Amazon EKS that could be improved is the manual process for adjusting the number of nodes. When I've already defined configurations in Docker or YAML files, it seems unnecessary to go back and make similar adjustments in the console.

I have been working with Amazon EKS for 4.7 years.

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

Currently, I am using GKE in Google Cloud, which is similar to Amazon EKS. The differences between GKE, Amazon EKS, and AKS mainly come down to minor functional variations; overall, they provide similar capabilities.

Regarding the pricing and licensing of Amazon EKS, I am not entirely certain, but from my perspective, it's somewhat comparable to AWS's compute instances. While it may be on the pricier side due to being a managed service provided by Amazon, the features and functionalities justify the cost, especially for applications requiring reliability and scalability.

I participate in the setup and deployment of Amazon EKS, though I don't do it directly through the console. I use a third-party application called Argo CD, which allows me to deploy Kubernetes applications without accessing the Amazon console directly, making the process efficient and straightforward.

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

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.

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.

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.

My main use case for Amazon EKS is for implementation and sustainable services and microservice application on a critical structure and services deployment.

On our application, we have more than 20 services and microservices such as authentication, login, account management, a notification service, and a billing service, which all work together to structure a heavy, useful application.

The best features Amazon EKS offers are scalability and deployment control, the ingress configuration regarding path pattern and host header to get all the services and microservices, and the HPA configuration.

The biggest difference, or the most important aspect to me, is the scalability, because you can easily scale any service or microservice to handle security during high changes in connection flow, and it is useful for the application and helps day-to-day by giving us reliability and stability so we can perform all maintenance and deployment of our system.

Reliability is a very important thing. Security and operational consistency are very important aspects, and the flexibility offered in node management and network options is also valuable. Amazon EKS is a service that is reliable and scalable, and it gives us a solid and dependable solution.

I think sometimes the documentation is not so clear and not so fast to provide more in-depth instruction and examples of bigger and critical implementations, so some difficulties for us sometimes take a lot of time to understand, test, and to put into production with security and guarantees.

I have been using Amazon EKS for almost five years now.

I advise doing a POC first and getting all the details, testing, and having a very good alignment between DevOps and development departments, and prepare all the CDN and how the connections get into your cluster, and how you configure your ingress and how to prepare every service or microservice to receive that with secure and optimized code, process, and communication with other resources. I would rate this product an 8.

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.

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.

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.

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.

We are migrating our services into container services. We build websites and all of our products' backends are based on Amazon EKS.

The simplicity and management portal make it a neat solution. You don't have to fiddle around with too many open source tools, as it's just a comprehensive solution.

We use the pipeline, which is critical for us to deploy automatically. This eliminates manual intervention, which is really helpful.

We initially had some issues getting the logging out of it, because what they're providing into CloudTrail is what we get. If we wanted to go in-depth, we had to deploy third-party tools. We did try the sidecar way of getting the logs. Ideally, if the platform was able to provide those kinds of valuable logs, that would be beneficial. Adding enhanced logging capabilities would be a nice improvement.

We have been using the solution for three plus years.

Time to value is good with fast deployment and very good documentation that is really helpful.

I don't personally deal with the costing part, but I think it's a fair amount. That's the only reason we're using it continuously, as otherwise we would have moved somewhere else.

The implementation was done in-house.

On a scale of 1-10, I rate this solution a 9.