Amazon EKS Reviews

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.

Public Cloud

Amazon Web Services (AWS)

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.

Hybrid Cloud

Amazon Web Services (AWS)

I use Amazon EKS to provide the computing power for my applications. We have over thirty clusters in Amazon EKS. Our team uses Amazon EKS to deploy new applications using Helm and to manage our infrastructure. We use Amazon EKS to scale and deploy more applications using different namespaces. Amazon EKS services help us provide clusters where we deploy APIs, services, cron jobs, and other applications to support our services.

The features I find most valuable in Amazon EKS include the VPC CNI, which provides networking inside the cluster, and the EBS CSI driver, which is an example of the add-ons used with Amazon EKS. Kube-proxy for DNS is also a valuable feature. The features we use for managing container applications, like scheduling and scaling, simplify our use of Amazon EKS.

I would like to see improvements in the management capabilities that are native to AWS for Amazon EKS. Our current use involves using a different tool to administer the management, and I believe enhancing this aspect would be beneficial.

I have been using Amazon EKS for four or five years, mostly in financial services.

During the initial setup, I needed to learn about Docker, networking, and microservices, which was a challenge as I didn't have a background in microservices. My first application took three months to deploy, but now, with automation and CI/CD, we can deploy cycles of twenty applications swiftly. Initially, two people were required to deploy Amazon EKS.

Amazon EKS is very stable, and when properly configured, I rate it ten out of ten. In my notes, it's a nine. I did experience some challenges with network stability but was able to resolve them with AWS technical support.

We use the Horizontal Pod Autoscaler (HPA) to provide elasticity to our applications. This allows us to scale our applications or APIs as needed, offering reliability through the automation of scaling processes. I rate the scalability as higher than eight.

Technical support from AWS for Amazon EKS is excellent. I rate it eight out of ten. Recently, we faced a network issue, and AWS technical support provided guidance to resolve the problem successfully. Their support was crucial for directing our efforts and solving our IP-related issues.

Positive

My first experience with Amazon EKS was difficult, and I would rate the initial setup as two because it was challenging without prior experience in microservices. However, after the initial setup, my perception improved, and I now rate it as five or six.

Two people were necessary to deploy my Amazon EKS.

We are making a significant effort to transform our usage of Amazon EKS, which was previously rated as eight or nine in terms of cost. Now, it stands at six or seven due to optimizing our workload.

Overall, I rate Amazon EKS as a nine out of ten. It's a very stable and reliable product.

Amazon Web Services (AWS)

Our primary use case is related to our ecommerce solution, which is very high in terms of data in the database and products. It has one hundred thousand first line items. We developed a system connected with AWS services to translate search keywords into different languages and improve search results accuracy on our ecommerce site.

The scalability has really helped us a lot in enhancing the customer experience and ensuring quick results. The ROI is really good, especially when compared with other services on-premises.

Amazon EKS provides good support. The integration and stability are clear and reliable. The scalability is excellent, allowing us to efficiently handle customer experiences and improve operational efficiency.

Sometimes, we face minor connectivity issues. However, it depends on the applications we are using. Improvement might be needed based on different use cases.

We have been using it since 2015.

The stability of Amazon EKS is clear and reliable.

Amazon EKS's scalability is clear and has improved our operational efficiency a lot.

The customer service and support are good, and we have a paid subscription that provides priority support.

Positive

The initial setup was handled by third parties. It involved some complexities, and appropriate inputs were necessary.

We worked with a third-party team for implementation, including many developers.

We did several ROIs, which showed positive results. It's particularly beneficial compared to investing in hardware.

The licensing cost is acceptable.

Before implementing, ensure thorough research and ROI analysis. The implementation should be handled by experienced personnel.

I'd rate the solution eight out of ten.

Public Cloud

I am working mostly on AWS infrastructure services, such as EC2, EKS, RDS, CloudFormation, IAM, and CloudWatch. I have around one year of experience with Kubernetes and have been using AWS services continuously for three years. My responsibilities include working on server storage, containerization, monitoring, and access policies.

Simplifies Kubernetes setup and management.AWS handles cluster upgrades, patches, and availability.Seamlessly integrates with AWS services like IAM, CloudWatch, and VPC.Access to advanced networking, security, and monitoring tools.EKS automatically deploys the Kubernetes control plane across multiple AWS Availability Zones for fault tolerance.

EKS incurs an additional management fee ($0.10 per hour per cluster) along with EC2 or Fargate costs.May be expensive for smaller workloads compared to alternatives like AWS ECS.Requires expertise to configure and manage Kubernetes resources effectively.Networking (e.g., setting up VPCs, subnets, and service endpoints) can be complex.Simplifies managing multiple Kubernetes clusters, especially for organizations with hybrid or multi-region setups.Integrated dashboards for Kubernetes metrics, logs, and traces.Simplifies observability without needing third-party tools.

I have around one year of experience using Kubernetes with AWS.

In my project, AWS EKS has shown stability without any issues.

EKS offers excellent scalability, especially compared to Docker Swarm. The ability to scale based on requirements by deploying additional containers is a strong point for Kubernetes.

I have not contacted technical support regarding EKS.

Positive

I have explored Google Kubernetes Service in my personal projects but did not work on any other Kubernetes projects before EKS.

The initial setup is relatively straightforward when using the AWS Management Console. Setting up clusters and nodes is simplified through AWS's interface compared to on-premises. It took approximately 15 to 20 minutes to complete the setup.

I do not have specific details on EKS's pricing and licensing compared to other services. However, in general, deploying in the cloud offers lower latency and high availability and reduces manual intervention and responsibility, leading to some operational efficiencies.

I have worked with Google Kubernetes Service in my personal space but have not evaluated others for professional use.

For large-scale enterprise solutions, Kubernetes is recommended due to its scalability. Despite costing considerations, EKS alleviates the burden of procedural complexities, making it suitable for enterprise-level applications.

I'd rate the solution eight out of ten.

Public Cloud

Amazon Web Services (AWS)

For EKS, we deployed a Django application. The application built the whole image and stored it in ECR (Elastic Container Registry). We stored the code repository in GitHub, but the image was in ECR. We also had another repository for the Kubernetes manifest files. So we were deploying it in a different image, and the code was in a different image. We had a whole pipeline for deployment, from CodePipeline to ECR, and then from ECR to Kubernetes.

I work with different AWS solutions, such as Elastic Beanstalk, AWS Lambda, DynamoDB, and VPC. I use services like EC2, S3, and VPC every day, so I'm not including those. I've also used API Gateway, and currently, I also use AWS Bedrock.

The good thing was the integration of services. The only thing we had to think about was how we were pushing the code to GitHub or Bitbucket. After that, everything was taken care of by AWS. 

Everything was connected: the code and the real-time deployment. Testing was done within the same pipeline using CodeBuild. CodeBuild was handling multiple tasks: testing the code, deploying it to ECR, and then running it on AWS Fargate for development or testing. Once it was working fine, we had an approval stage. After approval, we deployed it to EKS using the command line from the same AWS CodeBuild process.

The scalability of EKS is good. We've compared it with multiple platforms, and we've also worked with GCP. There are more good options available in GCP compared to EKS.

But the good thing about EKS is that we can use it for serverless deployments using Fargate. It gives you two options: deploy on EC2 or deploy on Fargate. EC2 runs 24/7 and costs you money, but Fargate only runs when you need it. So EKS was really helpful for saving costs with that serverless capability.

I would like to see a warm-up time for AWS Fargate, similar to what GCP Cloud Run has. This would improve internal security. I would also really love to see lower costs compared to other cloud vendors. AWS can get quite expensive.

I've been working with EKS on and off for the last two years. Some of the projects were my own, and some were development projects.

They have good documentation and lots of blogs on Amazon AWS, so we mostly follow those. We haven't reached out to technical support directly. We had a plan for technical support, but it took them more time to fully help us. 

Sometimes the issue is on our code side and not on AWS's side. Getting the customer service and support involved in our whole process takes a long time. It's better to research for a few hours and fix it yourself rather than waiting for a week or so.

GKE gives you really good monitoring and logging, where you can see every bit of information flowing in your environment. AWS provides the same thing with CloudWatch, but it's much easier in GKE to see what's exactly going on. So monitoring and the transparency of what's happening would be one thing AWS needs to improve.

The pros of EKS are that it makes deployment really easy. You just need to package your image in ECR, and then everything goes very smoothly. You don't have to worry about running or managing Kubernetes. It gives you a managed control plane, and they replicate the control plane over different regions. So there's very little chance that it will go down. Reliability is really high with AWS.

When we started we had an issue with rollbacks. We had problems because we had to specify certain AWS parameters in order to deploy it properly. We consulted the documentation and resolved it that way.

We did some testing, and that took about one month with it. Then we started with a very small infrastructure on EKS, migrating some of our traditional websites to EKS directly. So, the initial setup took about two months. 

But we didn't use it for microservices; we only used it for two services: one was our platform service, and the other was Redis.

In my case, I handled the deployment part. I had a manager, so I just took his approval and gave him the deployment design. He was overseeing everything, but I was doing almost all the AWS work. The developers were really helpful in making the code run correctly with the image versioning.

Users have to maintain things. For example, we faced an issue where we had a lot of requests coming in, and we weren't ready with enough resources at the time. We had to manually increase the Kubernetes nodes. That was an issue with horizontal scaling. It was our mistake because we didn't automate it.

We shifted from EKS to GKE (Google Kubernetes Engine). We are saving around 20% with that change.

I already have recommended it to many people. If you're using AWS for other services, definitely go with EKS because it doesn't make sense to move to another cloud vendor if you're already using everything in AWS. The integration is really good. You get AWS WAF (Web Application Firewall) on top of it, load balancer, GuardDuty, and Inspector. So security-wise, it's really nice to have EKS surrounded by those security tools.

My advice would be to try to go with AWS Fargate initially. Try to understand how ECR (Elastic Container Registry) works because it also costs you money, so make sure your image isn't too big. And if you can, go with AWS CodeCommit, it makes things very fast. And for EKS, they can use Fargate with EKS as a service. So, users don't have to worry about scalability and reliability. It's totally managed from the user's end.

Overall, I would rate it an eight out of ten. 

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.

Public Cloud

Amazon Web Services (AWS)

Our typical use case for Amazon EKS is that we have a number of applications and microservices that we host in EKS. We have a separate code base for the infrastructure platform, and the microservice team and the application team will be deploying their microservices on their own. We have configured it in a way that it could be easily accessible for developers as well as the platform engineers; we just platformize things. Earlier, I was using ECS, and the reason we use Amazon EKS is for better adaptation of Kubernetes, fitting our multi-tenant model.

The best features of Amazon EKS are that it is very plain by itself, but we use a number of optimizations, such as Carpenter for scaling and node auto-scaling, and Keda for application and microservices auto-scaling, as an event-based auto-scaler. Additionally, we use Portainer less, and for configuration, we utilize Cert Manager and Istio. It's not only Amazon EKS but a combination of various components within it.

By default, if you just install Amazon EKS, you can deploy your application, but to have it enterprise-ready, you have to configure a number of other things that will boost productivity.

Amazon EKS's deep integration with AWS services, such as IAM and elastic load balancing, has created some challenges. For example, we have something in place already, and there are some issues with enabling FIPS, which is FedRAMP compliant for the load balancers. You cannot change the SSL policy for the load balancer; I am not sure if it has been patched by AWS yet. However, apart from that, we use it effectively, and it is more flexible.

Regarding built-in observability in Amazon EKS, there is CloudWatch and CloudTrail. However, you cannot profile the applications; we can collect logs in S3, but there is no streaming solution available. Only CloudWatch exists, so we use other tools for observability and do not depend solely on CloudWatch, only relying on it for crucial workloads and infrastructure logs.

Amazon EKS can be improved by having the maintenance of Kubernetes versions managed better, as everything is handled by the Kubernetes team and possibly a separate team at AWS. We have to constantly maintain upgrades and ensure EKS add-ons are up-to-date, requiring us to upgrade the Kubernetes version and releases. They could provide a managed service in the backend instead of making customers handle it; we are currently doing it, but it's a regular activity we do per quarter.

I have around six years of experience with Amazon EKS.

Amazon EKS is a stable solution, as it is only available in AWS alone.

It is a scalable solution for us.

Before using Amazon EKS, I was using ECS. I switched from ECS to Amazon EKS because our product design changed. With numerous small services that you don't want to manage the backend infrastructure for, you can easily deploy and let it be with ECS; it is a more straightforward solution. However, considering cost with Amazon EKS, it may be pretty high, but it serves its purpose very effectively without management overhead.

If you are going with Amazon EKS, you must change your deployment strategy and develop applications for Kubernetes, writing deployments and pods, or stateful sets, which provides more flexibility. There are pros and cons to both solutions, and you have to evaluate which will suit your use case. In our situation, we had some applications in ECS as in Amazon EKS, and that was an architectural decision discussed internally within teams.

The initial setup with Amazon EKS was hard initially, but being accustomed to it now, it's not that difficult; it's relatively easy.

We have seen ROI with Amazon EKS; we have a separate team actively working on it. We have cost explorer available, and a bill forecast based on usage allows us to determine whether resources are underutilized or overutilized. You can generate reports and analyze them. I have done this for ECS, but for Amazon EKS, I haven't worked on cost savings directly, as there is a separate team responsible for that.

My experience with pricing for Amazon EKS is limited as there's a separate team for that, and I do not have much knowledge of specifics. However, the pricing is based on the instance type we use in the EKS node group, so it should cover that aspect; their pricing is generally easy to understand in terms of instances.

We are using a cloud deployment model. On a scale of one to ten, I rate Amazon EKS an eight.

Public Cloud

Amazon Web Services (AWS)