Amazon EKS Reviews

For our microservice architecture, where we have multiple services for our business use cases, we have been using Amazon EKS from the very beginning.

The integration with IAM enhances the authentication processes as it prevents multiple outages, failures, and mis-deletions from users.

The Amazon EKS support for AWS tools integration is very effective because it's within the ecosystem of AWS itself, integrating almost with everything. Amazon EKS itself uses EC2 instances, which are the basic services that Amazon provides, on top of which we have VPCs, security groups, and all.

The self-healing feature on Amazon EKS identifies when one of the nodes goes down and spawns a new node, degrading the older node, which helps to minimize our administrative burdens by reducing one stage of complexity on our SRE team.

The dashboard of Amazon EKS is very effective, where I can see all the nodes, the pods that are present, and it also shows the current CPU utilization, memory utilization, along with the pods that are scheduled on the nodes. Those insights in one place are very valuable.

We have utilized Amazon EKS's integration with the IAM solution.

We are utilizing the self-healing nodes in Amazon EKS.

I have one suggestion for Amazon EKS. When working on microservice architecture, we need to use that context and have K9s installed for a graphical user interface to check pods and nodes in a clear-cut manner. If that support is added within Amazon EKS itself to check all the config maps and everything within the UI itself, that would be very beneficial.

I have been working with Amazon EKS for one and a half years.

The initial setup of Amazon EKS was completed by other teams, and they performed it straightforwardly as they had some orchestration script which sets up the EKS cluster and has multiple add-ons to be added.

Starting to work with the Amazon EKS product was straightforward for me since I had previously taken a course on Kubernetes.

The main benefits I have seen from using Amazon EKS are the reduced complexity overall, where Amazon manages everything effectively, and the other benefit is the microservice architecture. Amazon is flawless in most cases, though we encountered a few unknowns from the EKS cluster itself. Apart from that, it is always up, and we have the support team for Amazon EKS as well. Our SREs had interactions with EKS, and within minutes or within 10 or 20 minutes, we would get the EKS cluster up if there was an issue.

There is one person from AWS who acts as a bridge between our team and their team, so we can ask them if we have an issue.

Positive

Before Amazon EKS, I was in college and did not use any other Kubernetes solutions or container management products.

The initial setup of Amazon EKS was completed by other teams, and they performed it straightforwardly as they had some orchestration script which sets up the EKS cluster and has multiple add-ons to be added.

The initial setup of Amazon EKS was completed by other teams.

The pricing of Amazon EKS is subjective because it depends on the use case and the instances that we are using. Amazon provides everything, every instance, and it also gives a cost at the fore-end, so it depends upon our use case whether we want them to be higher cost or lower cost.

We have not evaluated any other options. From the very start, we were using AWS only, and it has been good and is working fine, so we never evaluated other options.

I am not aware of the automated patching feature in Amazon EKS.

I work with Amazon EKS and am still currently working with it.

We use Kubecost for managing Amazon EKS, which is an external tool we use to find all the healthy status, memory utilization, cost, and all for our EKS cluster.

My advice for organizations considering Amazon EKS for their environment is to proceed with it, especially if they are trying for a microservice architecture. It's already very good, with no flaws. Just one thing is to have a look at the cost of the instances they are trying to provision.

I rate Amazon EKS 10 out of 10.

We use Amazon EKS for hosting our applications. It is also a version of compute service with its own perks. Amazon EKS is built on Kubernetes. Kubernetes is complex and is not something used for basic or simple applications due to its complex nature. It is really meant for complex apps such as banking applications or AI-enabled applications that have many services.

When dealing with microservices, if an application has around 20 microservices, then Kubernetes generally begins to make sense. Then it becomes a question of whether to host it on Amazon EKS, Azure Kubernetes Services, or Google Kubernetes Engine. That is basically what we use Amazon EKS for.

Amazon EKS is fairly reliable. The latest feature that was added last year, Amazon EKS auto mode, helps manage compute instances and EC2 instances. Amazon EKS auto mode is a very good addition as it helps reduce stress since users do not have to worry about upgrading Kubernetes versions. For example, when Kubernetes 1.34 is released, Amazon EKS handles the upgrade automatically.

Another beneficial feature of Amazon EKS is the Fargate offering. It helps run some compute instances on AWS Fargate, which means they only run when needed. Unlike typical EC2 instances that keep running once turned on, with Fargate, charges only apply when someone visits that service. For instance, in a banking app with multiple services, including a reviews service, Fargate can be utilized to ensure charges only occur when someone actually uses the review feature.

Amazon EKS is fairly stable and highly available. Once configured properly, it requires minimal maintenance. It integrates effectively with other services such as API Gateway, security groups, and load balancers.

The integration capabilities could be improved compared to Azure. While AWS services are integrated with Amazon EKS, there is room for enhancement.

For example, Azure DevOps provides better pipeline integration. When writing pipelines in Azure DevOps, users can easily import various built-in tasks into pipeline YAML files, such as kubectl tasks or native Kubernetes plugins, once a service connection to Azure is created.

We encountered challenges with WebSocket integration when implementing chat functionality on Amazon EKS. The chat service, which was part of our microservices running on Amazon EKS, needed to be exposed on application load balancer. Despite both application load balancer and network load balancer having native WebSocket integration on AWS, the connections were unstable. This required extensive tweaking of network load balancer configurations to manage API calls through the API Gateway. AWS could improve WebSocket integration across API Gateway, network load balancer, and Amazon EKS.

We have not used it recently because we prefer to make patches ourselves.

When auto mode is enabled, self-healing functionality becomes active. If a node encounters issues or someone makes incorrect configurations, Amazon EKS automatically resets it to maintain standard configurations. This is particularly useful when someone SSH's into Amazon EKS instances and modifies Linux kernel configurations, as the self-healing node resets it to normal, helping reduce administrative burden.

We only escalated questions regarding increasing CPU and memory allocations for Fargate. We contacted AWS through their service quota system. The process required submitting a request with justification for increasing the quota for CPU and memory on Fargate. The resolution was quick after providing a brief justification for the quota increase.

Positive

The setup process is very straightforward.

When considering Amazon EKS, it is important to use Infrastructure as Code (IAC), not just Terraform. Having a repeatable configuration of infrastructure as code is essential for creating clusters, as manual cluster creation is not common in professional production environments.

It is crucial to consider Fargate carefully, as it can help save costs. Fargate is particularly useful when parts of an application or the entire application are not used constantly, as it can reduce costs compared to running on EC2 instances.

On a scale of 1-10, this solution rates as an 8.

I am actually the end user myself without a third party at my company.

I am using Amazon EKS for my Kubernetes with a private ECR on AWS. The application focuses on workforce software as a service.

Amazon EKS adapts and fits with my needs. It provides correct tools since I still need to configure manually some nodes or setting an SSH into the nodes.

I love the automatic automation of Amazon EKS as it manages my Kubernetes. It has a log dashboard for my Kubernetes, and I can manage it easily. Sometimes I need to manually manage using Amazon EKS rather than ECS for fully managed service from AWS. There is more override capability for myself, so I can manually create another group for nodes when needed.

Amazon EKS is integrated with IAM. If I want to allow my coworker to access Amazon EKS, I can allow some permissions with least privileges. For example, if my colleague wants to look at application logs, I can grant permission only to see the logs without editing or deleting the pods.

Amazon EKS helps significantly with the development process because I can rest without worries about outages. If an outage occurs, Amazon EKS automatically replaces nodes. It helps with automation in the development lifecycle.

I am using self-healing nodes on Amazon EKS when deploying new nodes. If nodes become unhealthy, Amazon EKS replaces them with new ones, which helps with my role as a DevOps Engineer.

The benefit of Amazon EKS's automated patching feature saves my time. I can leave it to automatically handle any node issues, which greatly benefits my job efficiency.

From my perspective, Amazon EKS is quite sufficient. The main issue is that Amazon EKS only has an update for Amazon Linux 2023. The challenge occurs when switching to a new operating system. Currently, I am using Amazon Linux 2, but according to AWS information, it will be deprecated. I hope AWS continues to support the operating system for Amazon Linux 2.

I started using Amazon EKS since late 2022.

For stability management, I can allow developers to access Amazon EKS with specific permissions using least privileges. This allows them to perform necessary tasks such as viewing logs without having the ability to edit or delete pods.

Amazon EKS helps significantly with the development process by handling outages automatically. When an outage occurs, it automatically replaces nodes, allowing for continuous development and automated lifecycle management.

I don't frequently communicate with the technical support and customer service of Amazon EKS. They are quite helpful since when I need to verify infrastructure issues from their side, I receive good information. I would rate them seven out of ten because sometimes communication can be challenging due to difference accents

Neutral

Before Amazon EKS, I only used plain containers using Docker on a plain EC2, without services orchestration from AWS.

Initially, I deployed Amazon EKS manually without infrastructure as code. The challenges were related to permissions, but I understood them adequately. It can be accomplished more easily using infrastructure as code tools.

The implementation was done internally.

This solution is very important since my applications must run continuously because many users need the application with minimal downtime.

The price of Amazon EKS is not a major issue since my company accepts it. The price remains good from the company's perspective.

I chose Amazon EKS because AWS provides robust and more complete services than other service providers. I selected Amazon EKS because I wanted to manually override settings. I prefer it over fully managed services like ECS or Fargate. For cost optimization, Amazon EKS fits my needs perfectly.

I am using RDS, EC2, S3, Route 53, and a load balancer alongside Amazon EKS. The overall rating I would give Amazon EKS is 8 out of 10.

Amazon EKS is used for running any type of application, and it is one of the more stable platforms. We use everything in AWS, CloudFront, and we probably have a hundred applications in AWS.

Several of our platforms have transitioned to Kubernetes because it is more economical than some other methods, and we have lots of apps that use Kubernetes.

The deployment of Amazon EKS took time mainly because of the amount of stuff we had to move, such as old legacy applications and systems, which need changes every few years, and AWS is just better.

We have several applications that run in Amazon EKS.

The best features of Amazon EKS include Kubernetes, as several of our platforms have transitioned to Kubernetes because it is more economical than some other methods, and we have lots of apps that use Kubernetes.

The support for AWS tools integration with Amazon EKS has influenced our management process significantly. The cloud affects everything, with probably 80% of our stuff in the cloud, mainly in AWS.

The self-healing nodes with Amazon EKS help minimize administrative burdens, and while I'm not a system admin myself, I do disaster recovery testing and resiliency assessments for cloud applications.

Improvements could include better support and pricing, which is always important.

There are definitely areas for improvement with Amazon EKS.

My experience with AWS products spans the last six, seven years.

Amazon EKS is stable.

Amazon EKS scales effectively.

I would rank their support close to a 10; they are very responsive.

Positive

The initial setup with Amazon EKS is straightforward, and all of our teams are involved with AWS. Some use EC2 containers, and I've seen everything there is to see in AWS.

Amazon EKS is easy to use, and you don't experience the problems that you encounter with some solutions like EC2 containers or S3 buckets.

The support for AWS tools integration with Amazon EKS has influenced our management process significantly. The cloud affects everything, with probably 80% of our stuff in the cloud, mainly in AWS, though we have some in Google Cloud and Azure.

In my role, I don't set anything up; I set up test disaster scenarios and have teams practice against those scenarios. We have encountered challenges during that migration process, and we utilize our AWS dedicated person whenever something arises that we can't handle or don't understand, so we can seek their help.

Amazon EKS helps us manage complex workflows effectively.

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

My main use case for Amazon EKS is that all the microservices are running on Amazon EKS, and I am using it as a container orchestration system.

A quick, specific example of one of my microservices running on Amazon EKS is that I have deployed our microservices using GitOps in Amazon EKS with Flux CD, and I have deployed multiple deployments and stateful sets in the same node in Amazon EKS.

One of the main use cases for Amazon EKS is that I am running our microservice in Amazon EKS, which will help in rolling out restart services pods without any downtime in Amazon EKS during any hotfix and releases.

The best feature Amazon EKS offers is that during maintenance, when I need to upgrade the Amazon EKS version, I don't need to worry about the master nodes as it is handled via Amazon. I just need to upgrade, and nothing else; all the things are managed by Amazon.

The managed control plane and automatic upgrades impact my day-to-day work because I don't need to take care of the master node; I just need to take care of the slave nodes and whatever node pool I am using. I only need to monitor those things and the services running on them, and I don't need to worry about the Kubernetes APIs inside Amazon EKS. This saves a lot of time, allowing me to focus on my microservices.

With Amazon EKS, I can set the cluster autoscaler, which helps when the load increases by increasing the nodes from the back end inside Amazon EKS. Additionally, I can set up Carpenter inside Amazon EKS, which will manage the load balance inside the particular node pool.

Amazon EKS has positively impacted my organization because whenever new code is being deployed, I can roll out the existing code with the new code without any downtime of the services. If I have a microservice with four pods, it will take down one pod and spin up a new pod based on my configuration, so it will not take my service down, allowing me to release new code with zero downtime.

Since using Amazon EKS, I have seen a great impact in terms of fewer outages because previously, I was using a monolithic architecture with microservice code running on different EC2 machines. Shifting the traffic to another EC2 instance took a lot of time, resulting in downtime of around one or two hours during previous releases, but with Amazon EKS, I can upgrade my code after checking in the lower environment, achieving zero downtime.

Currently, I have not seen any need for improvement in Amazon EKS.

If I could change or add one thing to Amazon EKS, I would say that sometimes when a pod scales up via HPA, it takes time for nodes to come online, especially if I have ten nodes running.

One needed improvement is that when using the cluster autoscaler, it sometimes fails to spin up new nodes, but this can improve with Carpenter.

I have been using Amazon EKS for the last six years.

Amazon EKS is stable.

Amazon EKS's scalability is excellent; I can scale based on the load required from my services within minimal time, upgrade my pods based on the node pool, and increase the nodes according to my requirements.

Customer support for Amazon EKS is fantastic; I can raise support requests based on the severity of the issue, and they will come to platforms like Chime or whatever tool I am using for meetings such as Google Meet or Microsoft MS Office.

Positive

Before using Amazon EKS, I was running multiple microservice codes on different EC2 machines, which took a lot of time to put a new code JAR into the machine and switch the traffic from the back side of Nginx. After using Amazon EKS, I can upgrade new code with zero downtime, saving a significant amount of time.

I have seen a return on investment with a lot of money saved, particularly in terms of revenue. Previously, taking downtime from customers directly impacted their revenue and indirectly affected ours. After using Amazon EKS, I can upgrade the latest code with zero downtime.

My experience with pricing, setup cost, and licensing is that pricing is based on my utilization and my workload.

Before choosing Amazon EKS, I evaluated AKS and GCP, but I chose Amazon EKS because of the good customer support I received while using it.

My advice for others looking into using Amazon EKS is that you can directly go to Amazon EKS; it is one of the best solutions in the current market, with a lot of features, allowing for scalability and code releases with zero downtime without worrying about hardware since AWS takes care of that.

Amazon EKS is deployed in my organization as a private cloud via AWS.

The cloud provider I use is AWS.

I purchased Amazon EKS through the AWS Marketplace.

I gave this review a rating of nine out of ten.

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

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

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

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

We have been using the solution for three plus years.

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

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

The implementation was done in-house.

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

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

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

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

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

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

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

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

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

I have been working with Amazon EKS for 4.7 years.

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

Negative

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

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

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

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

The main use cases for Amazon EKS are that we use it normally in some new projects to optimize our costs. Instead of having many ECS services running, we prefer to set up a Kubernetes cluster and set everything there. For me, it is primarily for optimizing our resources.

What I find valuable about Amazon EKS is that it helps us manage all the Kubernetes. It isn't the workload, it is the main part of the Kubernetes, the head of all the cluster. Automatic updates are available, and we can set everything we created in AWS in Kubernetes, including IAM configuration. We can create policies such as creating a private endpoint for S3. The integration of Kubernetes with the AWS ecosystem is the best feature that Amazon EKS provides.

The IAM integration in Amazon EKS helps enhance the authentication processes because we can do this in a more granular way. Using IAM, you can set exactly what the service needs. If a service or application needs to upload objects or data to S3, connect to RDS, or perform other tasks, using IAM is the easiest way. The benefit is that it works in a granular way and it's easy to set up and validate. When you examine the permissions and rules to ensure everything has the correct permission at the correct moment, using IAM is perfect because you can validate and set up everything effectively.

Amazon EKS's support for different AWS tools integrations has accelerated our application development because we can think about all aspects comprehensively. We can architect using AWS services and objects, and Amazon EKS accepts this seamlessly. We don't need to translate the idea for AWS. We can write this idea using AWS objects and services, and Amazon EKS corresponds to that. It accelerates projects and is easy to manage because we can use Terraform to implement it.

I am using the self-healing nodes in the Amazon EKS solution. We have a client with a production workload running on spot instances. When a spot or node crashes, Amazon EKS starts a new node and moves everything before the node stopped. This self-healing is excellent because we don't experience disruptions. We don't face situations where a node stops and we need five minutes to start a new one. We use it in specific environments and can observe the difference when enabling or disabling Amazon EKS self-healing.

We are utilizing the automated patching in Amazon EKS. The valuable benefits I have experienced using the automated patching feature for the Kubernetes clusters directly increase security. Kubernetes typically releases patches focused on security rather than new features. It's beneficial because we can focus on our work without constantly thinking about new patch releases or upgrade deployments. Amazon EKS handles this automatically for us.

We face some issues with Amazon EKS when using the node group to control which nodes can start. We have a limitation where we need to set just one kind of instance - only large instances, only small instances, or only extra-large instances. This is a problem. It would be beneficial if we could specify that certain containers or services start on small instances rather than large ones.

I am uncertain whether Amazon EKS supports all LTS versions, and I think this would be something beneficial. Additionally, AWS has great AI features, so when we need to make updates to Amazon EKS, it would be helpful if AI could assist with planning, identifying migration requirements, and considering costs.

I have been working with Amazon EKS for about two years in production. Including study time and other experiences, I have been involved with it for approximately four years.

I faced challenges in the initial stages with Amazon EKS. The main challenge is that when we set up the cluster, it appears as a huge infrastructure just for a small application. When you set up Amazon EKS, it is configured at a large scale by default. You can't start small and gradually expand. This makes sense because for smaller applications, ECS works effectively. If you want a more integrated ecosystem, you can use Amazon EKS. The challenge lies in migrating everything, as you can't start using Amazon EKS on a small scale. It typically requires a big cluster with one, two, or three nodes. We also faced challenges with developers needing to adapt their mindset to the new way of doing things.

I have escalated questions to the technical support of Amazon EKS two or three times, and they always provided good solutions. When we don't understand the questions, we schedule a call to demonstrate the issue, and we always receive the correct answer.

I reached out for technical support with Amazon EKS because we faced issues starting a service. The way we declared the services was incorrect, but we weren't aware of this. We called AWS support for assistance. Another issue involved a security problem that we identified and reported to AWS.

I would rate the technical support of Amazon EKS a 10. The documentation is good, and when human interaction is needed, it's readily available.

Positive

From my perspective, I don't see any disadvantages of Amazon EKS compared to competitors in the market. Amazon EKS represents the state of the art. While Google has a powerful engine that offers more granular control, the additional configuration can be overwhelming. Amazon EKS balances the power of custom configuration with ease of setup.

I find the pricing of Amazon EKS complicated because I live in Brazil, where we use reals. With the exchange rate and taxes, the price appears six times higher. However, when viewed in dollars, it offers great features at reasonable pricing. Lower prices are always beneficial, and a reduction in hourly cost or promotional discounts would be appreciated, but the current price-to-benefit ratio is worthwhile.

My advice to other organizations considering Amazon EKS for their environment is to plan carefully. I strongly recommend planning and reading the documentation because Amazon EKS is resourceful and typically offers multiple ways to accomplish the same task. Careful planning, reviewing case studies for comparison, and thoughtful migration to Amazon EKS are worthwhile investments. Overall, I rate Amazon EKS a 9 out of 10.