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.

I use Amazon EKS for managing production environments. I have worked for different companies over the past three years, managing microservice applications on Amazon EKS to deploy application code to the environment, including the production environment. We use DevOps methodology to deploy these services.

The most beneficial aspect of Amazon EKS is that it helps manage the Kubernetes master node, so I don't need to maintain the master node, including tasks like upgrading. This allows me to focus on business code. If using services like Fargate, I only need to maintain my workload, simply uploading code that will be deployed to the Kubernetes cluster. This is especially beneficial for startup companies that lack the technical resources to manage the Kubernetes cluster. Furthermore, Amazon EKS allows me to utilize Kubernetes cluster-level expansion. If there’s insufficient resource on a machine, the cluster can automatically expand to add new nodes.

Although Amazon EKS is popular, there are areas for improvement. It could support more scenarios and plugins. Currently, some third-party plugins, like certain network plugins such as Weave CNI, might not be fully supported. 

I have been working with Amazon EKS for more than three years.

I haven't found any performance issues with Amazon EKS so far. To avoid potential performance issues, it is important to plan resources initially, ensuring there are enough compute resources like nodes to host applications.

Amazon EKS is very scalable, but scaling can sometimes cause trouble. When Amazon EKS scales up or down, there might be occasional intermediate pod interruptions, though it's rare.

I have escalated some questions to AWS tech support before. I once faced a random issue where a pod abruptly shut down and restarted. Upon escalation, AWS helped me find the root cause. Overall, I would rate AWS tech support an eight out of ten.

Positive

I have experience with Azure AKS and some exposure to Google GKE. However, I mostly have experience with Amazon EKS.

When I first set up Amazon EKS, I faced challenges because there are different setup methods. Using the console does not align well with DevOps. It is better to use EKS CTL or Terraform's IAC tools. Configuring role permission policies is the most challenging part, ensuring Amazon EKS has access to different services or databases.

I have experience with Azure AKS and some exposure to Google GKE.

I would recommend Amazon EKS for large companies, especially banks, due to AWS's extended support for Amazon EKS, its availability, and reliability. Amazon EKS offers a strong solution as part of a full suite, but it should be integrated with services like Lambda for a complete solution. On a scale of one to ten, I rate Amazon EKS an eight because there is still room for improvement. The overall product rating is eight out of ten.

The primary use case for Amazon EKS involves microservices and micro frontends.

The most valuable features of Amazon EKS are its scalability features.

There is room for improvement in the interface of Amazon EKS. Additionally, they are involved in activities like pipeline management, pod checking, and error logging, which could suggest areas for further improvements.

I have more than three years of experience working with Amazon EKS.

I would rate the stability of Amazon EKS ten out of ten, indicating it is highly stable.

I would rate the scalability of Amazon EKS an eight out of ten, suggesting it has high scalability.

I do not have experience contacting Amazon's technical support.

I was not involved in the setup of Amazon EKS.

I would recommend Amazon EKS to other people for various reasons. That said, I also rate this solution seven to eight out of ten overall.

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.

We use EKS in our company to run containerized applications. I work in the container ecosystem team, and we manage EKS clusters for our developer teams so they don't have to. We provide them with the necessary tools to run on top of the cluster.

EKS helps us simplify and speed up cluster management. We don't have to take care of cluster updates; we just initiate the update, and AWS handles it. The same goes for some of the AWS-managed add-ons.

The biggest improvement is that we now have more time. When we shifted the responsibility of cluster management and updates to AWS, we had more time to develop solutions that make life easier for the developers. 

Application deployment is more automatic. They don't have to issue cluster commands; they can simply do a commit into our internal GitHub Enterprise, and our tooling will deploy or update the application on the cluster. That's probably the biggest benefit because we had time to develop such solutions.

From my personal perspective, I think it's good that we can use AWS CLI to manage the cluster, and that way, we can automate the work via scripts. Of course, the way that we just issue a command and AWS handles the work, like with cluster updates, is also valuable. That's probably one of the reasons why we use it.

Sometimes I have trouble because, in our corporate network, there are various networks, etcetera. It's difficult to connect to some of the clusters, and it's easier to go through the UI when troubleshooting something. At some points, the UI seems limited to me with the functions it provides. 

You can get information like what kind of port is running on the cluster, but I haven't really explored the UI so far, so it's difficult for me to see the logs, for example. Or sometimes, you are only limited to the basic Kubernetes things. 

We have certain customizations installed in the cluster, and for that, you really have to use kubectl from the command line. You are not able to use the EKS UI to list certain custom resources. So maybe there can be some kind of improvement, but maybe it's just me that I haven't really explored the UI that much.

I have been using it since February. 

I don't really remember any issue with EKS, the product from AWS as is. There can be some issues when there is a bigger outage on the AWS side; it's either some kind of network outage when we cannot reach AWS itself or something similar, but I wouldn't blame EKS for it.

When we had problems with the cluster itself, I think it was more about some issue that either we as a team introduced by human error, from some configuration mistake, or our customers sometimes made mistakes. And maybe there are issues when the application running on top of EKS somehow gets into some loop or something and then doesn't work correctly, but I wouldn't really attribute that to EKS.

Because I've been in the team for a short amount of time, I don't really remember any big issue that was caused by EKS itself in the past six months at least.

It is scalable. We use the cluster autoscaler tool that spins up a new node when we need more, and that works nicely. So I think from the scalability point of view, it's okay. 

In the last six months, I don't really see any issue with scalability. We run around one hundred clusters. Some of them are quite small, really just the basics where we are running free master nodes in the free availability zones, just to make things according to best practices. So, really a minimal cluster. 

And there are also some really big clusters with over a hundred worker nodes. Overall, I think it's quite big. And with EKS, we are able to manage it quite well.

I have some experience with AWS support, and it was good. We were trying to solve something with one of the add-ons, and I think we solved it within a couple of days. We even had a call with one of the support engineers. So I think it worked out well. 

The issue was regarding one of the AWS-managed add-ons. I remember that we clearly had some kind of misunderstanding between us and technical support, and it seemed like either we were not able to explain it correctly or the guy wasn't able to understand us. But I remember that somehow we solved that issue. So at the end, it was okay.

Neutral

The deployment process of EKS was done before I joined the team.

For me, EKS UI is nice, and it was quite easy for me to get familiar with. I find the AWS CLI quite nice to use as well. I've been working in IT for some time now, so I have some level of experience. I guess these things come sort of naturally to me now, such as how to use the tools that are provided by companies. It's usually no issue for me.

From the maintenance point of view, I don't know much about how things are backed up, etcetera. I think that is exactly why we use EKS because we don't really have to take care of cluster backups. We can simply issue a command, and the cluster will update. If we were to do cluster updates manually, it would be more work. We would have to update the worker nodes and then update the master node one by one. AWS now handles all of this. So I think from the maintenance point of view, it's great, and that's why we use it because it's now much more simple and faster for us.

We still see the benefits of using this solution because we are using it. And we actually plan to transfer all our workloads to EKS if things were ideal. But for some legal reasons, we still have to manage some on-premise clusters, but I think the benefits are there.

If you have the money, I would recommend the EKS product to other users who are looking into implementing it. It's a good tool. It really takes some of the management burden off your back.

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

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. 

We use Amazon EKS for our proprietary solutions and applications. 

Amazon EKS is very scalable. 

Amazon EKS needs to improve customer operations and technical support. 

I have been working with the tool for five years. 

The tool's stability is high. 

We don't need technical support at the moment. 

The tool's deployment is not complex. 

Amazon EKS is a good investment. 

The tool's pricing is good. 

I would rate Amazon EKS an eight out of ten. 

We deploy different solutions on the EKS cluster for our clients to use.

Since it is a managed service of AWS, Amazon EKS helps us in the managing and autoscaling of services. We don't have to worry about multiple things like managing the nodes or IP addresses and can focus on our work.

Through Amazon EKS, we can have the blue-green deployment very easily.

The management of the nodes in Amazon EKS should be improved. AWS should reduce the constant upgrades of the nodes of Amazon EKS or EC2 machines.

I have been using Amazon EKS for almost two years.

I rate Amazon EKS a seven out of ten for stability.

I rate Amazon EKS a nine out of ten for scalability.

The solution's technical support is very good.

Positive

The solution's initial setup is straightforward for us because we use Terraform scripts, which we have written and can reuse. It is the same for the console.

If your application goes to production, you will definitely see an ROI with Amazon EKS.

The solution's pricing is fair enough and a little less costly.

I would recommend Amazon EKS to other users.

Overall, I rate Amazon EKS an eight out of ten.

We have a service hosting platform, and we use Amazon EKS for hosting web services.

The most valuable features of Amazon EKS are its auto scaling ability and the ability for service discovery.

Amazon EKS's vulnerability management of data could be improved. Also, concerning vulnerability and version upgrades, many more things could be pulled into the control plane rather than keeping it in the data plane and having the users figure out how to upgrade their portions.

I have been using Amazon EKS for five years.

Amazon EKS has good stability.

Amazon EKS's scalability is very low. Quite a few people are using the solution in our organization.

We had no issues contacting Amazon EKS's technical support and usually got the necessary support. However, as with any Kubernetes installation, only the control plane is covered by Amazon, not the data plane. So if there are issues on the data plane side, Amazon cannot be of much help.

Amazon EKS’s initial setup was moderately easy. Amazon EKS's deployment was fast. We took the help of an automated deployment system, and the deployment was done in a couple of minutes.

We have seen a return on investment with Amazon EKS.

Amazon EKS’s pricing is ok compared to its competitors.

Amazon EKS is a good platform to use, but scale up before you start deploying in industrial quantities.

Overall, I rate Amazon EKS an eight out of ten.

It is challenging to host the applications in the existing VPC of the solution. They should include some essential configuration features to it.

We have been using the solution for the last two to three years.

It is a stable solution. I rate its stability as an eight or nine. Although, it is difficult to find a stable version sometimes.

It is a scalable solution. I rate its scalability as a ten. We can quickly scale the cluster as per requirements. We have medium and enterprise business clients using the solution.

The solution's customer service is excellent. They also provide detailed documentation.

Positive

The solution's initial setup process is straightforward. It takes two to three days to deploy it in any infrastructure. We require one executive for implementation and around two executives for maintenance.

The solution is cheaper than AKS. Its license costs $73. The customers have to pay extra depending on the instances they want to deploy for hosting the application. I rate its pricing as a four.

I rate the solution as an eight. I advise others to use EKS ETL instead of AWS command prompt while deploying it.