Amazon EKS Reviews

I use Amazon EKS mainly for deploying my application onto the Kubernetes infrastructure, which is provided by the underlying Amazon infrastructure.

I have many services, many applications, and many web services and web applications which are deployed using Amazon EKS across different regions in Amazon web service locations and data centers.

Other than deploying applications onto Kubernetes infrastructure using Amazon EKS, I don't have any other use cases for this tool in my current organization.

Amazon EKS has very good scalability with 100% uptime and zero latency.

Amazon EKS is the most cost-effective solution that I am using currently. If I want to reduce my downtime, I can deploy it in a multiple region architecture, which can reduce the downtime.

It is a cloud-based solution which is managed by Amazon, a global cloud services provider. I have observed very negligible issues while running my applications on Amazon EKS.

It is very pocket-friendly, cost-effective, and the setup is very simple.

If you are running a few applications that require high scalability, you can go for Amazon EKS. It is a very good tool if you want a managed Kubernetes service. It will definitely work wonders for your project.

Currently I work for a financial global giant where a millisecond latency costs around a million dollars. With Amazon EKS, I have a lot of benefits.

The only thing I feel is keeping Amazon EKS updated with the current trends and requirements of the global giants which are using this tool.

I have been using Amazon EKS for the past three years. It is very brilliant.

I have worked on several improvements, particularly regarding instances when Amazon goes down, which is the only time I see issues in Amazon EKS.

It is pretty good and pretty stable.

I have not experienced any scalability issues.

I have not had any issues with customer service.

I have not used any previous solutions.

I don't have any alternate solutions.

It is already a great tool. It is already a very good tool in the market. I would rate this product a 10 out of 10.

Public Cloud

Amazon Web Services (AWS)

I mainly use the service for competition purposes, specifically for a specific competition.

The tools we are trying to see align with R&D's use cases, and then we are going to integrate them.

It provides benefits in terms of operational efficiency.

I consider Amazon EKS to be cost-effective.

The way we are using Amazon EKS is quite good, and it is fulfilling all the purposes we wanted to use it for until now. All the tools we are using in this project are AWS tools, and we are fully satisfied.

Nothing comes to my mind right now that could be improved in Amazon EKS, and I am not facing any issues.

I joined this project later, but I have been working with AWS for more than one and a half years now.

I have not contacted AWS technical support in this project, but in previous projects, we contacted them twice regarding database and other issues. They are quite good, and because it is a build project, we received immediate support within twenty-four hours. During the call, issues were solved immediately.

Positive

I have not worked with that tool currently or previously in Germany as we were not using it at that moment.

I am currently conducting POCs.

I have about four to five AI tools, with around one month of experience so far.

This is a new initiative that has not happened before.

I do not have hands-on experiences, and I have not tried Google Gemini yet. It is just a new feature we are trying to implement with AI.

With the POC, we are trying to figure out all those things, as it has already been done as part of POC, so I do not anticipate any issues later on.

On a scale of 1-10, I rate Amazon EKS a 10.

Amazon Web Services (AWS)

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

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

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

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

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

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

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

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

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

Positive

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

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

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

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

Public Cloud

Amazon Web Services (AWS)

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.

Public Cloud

Amazon Web Services (AWS)

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.

Hybrid Cloud

Amazon Web Services (AWS)

My main use cases for Amazon EKS are securing the clusters and providing mesh gateways between the clusters.

The features that I find useful in Amazon EKS are Istio, Webhooks, service accounts, and ReplicaSets with different service accounts and accounts that we work with.

The main benefits that I received from using Amazon EKS are that it is a managed cluster and offers simplicity.

I am not the right person to ask what could be improved in Amazon EKS to make this tool better for the next release. A continuation of the managed pieces would be beneficial because there is no integration of clusters. They are all separate with no real managed cluster type of capability.

I have been working with Amazon EKS for about 3 and 1/2 to 4 years.

The initial setup for Amazon EKS is not straightforward. Kubernetes is not an easy technology because there are many technologies in the cluster. You need to understand infrastructure code to deploy it and understand all of the requirements alongside it. You cannot simply request deployment of EKS clusters as it does not work that way.

I would rate the setup for Amazon EKS as a three because I need to have other technologies and other tool sets to make it work. I cannot just go through Amazon's console and request a three-node cluster deployment because that does not work.

Regarding stability, Amazon EKS is stable. Once it is up, it works. I would rate it as a nine.

For scalability, Amazon EKS is scalable. I would rate it as a nine.

I have never contacted customer support for any issues on Amazon EKS.

Neutral

The solutions I evaluated before working with Amazon EKS include Grafana, Prometheus, K9s, Istio, and Consul.

The main benefits in Amazon EKS compared to those tools are that it is a different tool set completely, and they provide better visibility and connectivity.

The initial setup for Amazon EKS is not straightforward. Kubernetes is not an easy technology because there are many technologies in the cluster. You need to understand infrastructure code to deploy it and understand all of the requirements alongside it. You cannot simply request deployment of EKS clusters as it does not work that way.

I would rate the setup for Amazon EKS as a three because I need to have other technologies and other tool sets to make it work. I cannot just go through Amazon's console and request a three-node cluster deployment because that does not work.

I suggest understanding the entire form before understanding Kubernetes. I would rate Amazon EKS as a seven out of ten because Kubernetes across all CSPs is complicated. I do not think it is an easy technology to give it anything more than a seven.

Public Cloud

Amazon Web Services (AWS)

I deal with application development. I have used AWS services for configuring elastic search, deploying in pods, and using the CI/CD pipeline with Jenkins to build and deploy applications.

Amazon EKS allows upscaling and downscaling by reallocating resources. It is possible to configure everything, monitor applications, and perform routing in pods, securing the application with whitelisting. Datadog can be used to trace applications for performance issues or errors. It is an effective platform for cloud operations on AWS, similar to its counterpart on Azure.

There is room for improvement in making Amazon EKS less error-prone when writing on the YAML file. A UI could help generate config files, simplifying the process for developers who are not architects. It is very time-consuming, and companies often expect developers to do everything, which can be overwhelming.

I have used AWS for three or four years, specifically for Amazon EKS for two years.

It is not easy to configure Amazon EKS, and it requires very detailed attention to configuration and deployment. It can be error-prone and time-consuming to redeploy until a stable configuration is achieved.

Amazon EKS is effective for scalability, providing features for upscaling and downscaling resources as needed.

Their technical support team is good, but they do not instruct on what to do. Having to know what questions to ask is essential. The documentation is adequate but could include more practical insights.

Neutral

The pricing structure is beneficial for large companies who pay for what they use, but it is not affordable for startups. Offering a free version could help small companies.

Overall, Amazon EKS is a great technology, but the knowledge required to use it is scarce. It is a skill in itself, and developers must undertake multiple roles, which can be difficult. I rate Amazon EKS a seven because it is not easy for developers to configure without a solid base of knowledge.

Public 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 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)

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.