Amazon EKS Reviews

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.

Public Cloud

Amazon Web Services (AWS)

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.

Public Cloud

Amazon Web Services (AWS)

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.

Public Cloud

Amazon Web Services (AWS)

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.

Public Cloud

Amazon Web Services (AWS)

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.

Public Cloud

Amazon Web Services (AWS)

I have a total of around four years of experience in multiple clouds, especially in AWS, and many times I used Amazon EKS for our multiple products and projects.

In our environment, we already have all the other infrastructure and services running on AWS, so we benefit from using Amazon EKS because the other services can easily communicate with it. For example, some of our services need to access S3, and our application objects reside there, so we can easily integrate them with Amazon EKS. We also use IAM rules for integration to provide granular access to resources. As per your question, in our environment, most of our clients and resources reside in AWS, which is why we prefer to deploy other services there, as most of our development environment uses Lightsail. This gives us an edge, allowing us to easily move from development to staging or production environments within the same cloud.

When we compare other clouds, AWS has an edge among all the crowded options right now. My observations and reviews with AWS also affirm this because it provides a user-friendly experience and offers many options that other clouds do not provide. When my team and I work with AWS, we always feel comfortable. I do not know the exact reason behind it; maybe we have a lot of previous experience, and we are familiar with AWS. That is why other reviews from my colleagues at previous companies indicate that AWS has some edge compared to other clouds.

I would recommend Amazon EKS to other organizations because it provides simple configuration, easy management, safety, granular access, and vast monitoring capabilities where we can easily monitor our clusters using CloudWatch. However, I would think about a clearer dashboard for Amazon EKS, but overall, I think it is sufficient.

When we need to deploy the application, we require a large number of instances. Therefore, I hope and believe I will not face out-of-capacity issues in AWS, especially since I have not yet experienced traffic around 50,000 plus, and I believe I will not face such issues in Amazon EKS the next time we deploy with a large number of nodes and worker nodes.

Additionally, the upgradation process of Kubernetes rapidly rolls out new releases, so it should be easier for our production environment to upgrade Amazon EKS clusters. Sometimes when we are going to upgrade the Amazon EKS cluster, we need to check the backups, and we should have options to export our configurations, such as exporting the configuration to S3 or somewhere else to find backups. Other tools, such as Velero, provide this functionality to back up configurations, so I hope this backup process will help us fulfill our backup policies and other requirements.

For the pricing aspect of Amazon EKS, one specific issue arises when we deploy applications, especially as we provide SaaS services to our clients. We would like to know the cost for each customer, but we face issues because AWS charges $70 USD for the Amazon EKS engine. We struggle to divide the worker nodes' fees and the engine cost among clients, as some users have low traffic and visibility while others have large amounts of visibility and traffic. Thus, we face cost-related issues when running multiple customers on the same Amazon EKS cluster.

I have been using the solution for approximately four years.

The initial setup and deployment of Amazon EKS was straightforward; I easily provisioned the correct cluster. Sometimes, due to the depreciation of the AMIs, AWS provides warnings to use the latest version of the EKS AMIs because some of our scripts or Terraform scripts are old. I think it is good practice for AWS to provide messages to the console to upgrade your cluster, but overall, my experience with provisioning the Amazon EKS cluster is good, and I highly appreciate it.

I have not faced any issues that require escalation to customer support, and until today, I do not feel any need to escalate anything to the support team. I am happy with the service.

To meet our requirements, our services need a large amount of CPU and memory, so we need high-spec machines. When we deploy applications, we require a large number of instances.

I have not faced any issues that require escalation to customer support, and until today, I do not feel any need to escalate anything to the support team. I am happy with the service.

Positive

I also work with other clouds, such as Oracle Cloud, but I feel comfortable with AWS because I faced some issues, such as out of capacity when we designed the infrastructure for our large traffic.

The initial setup and deployment of Amazon EKS was straightforward; I easily provisioned the correct cluster. Sometimes, due to the depreciation of the AMIs, AWS provides warnings to use the latest version of the EKS AMIs because some of our scripts or Terraform scripts are old. I think it is good practice for AWS to provide messages to the console to upgrade your cluster, but overall, my experience with provisioning the Amazon EKS cluster is good, and I highly appreciate it.

I used Amazon EKS through its console rather than through the AWS Marketplace.

I have not checked the pricing yet, but I will look into it to see if EKS brings ROI or a return on investment for us.

Regarding self-healing nodes in Amazon EKS, I have not worked on that self-healing feature.

For automated patching in Amazon EKS, I have not used that feature.

Regarding disadvantages of Amazon EKS compared to competitors in the market, I think every cloud provider has the same Kubernetes engine and worker nodes. However, I believe AWS provides a more user-friendly environment, which is why many of our customers are trying to deploy their infrastructure or applications on AWS. I do not think there is any specific reason not to prefer Amazon EKS.

I have not integrated IAM tools with Amazon EKS yet, but my other teams have. I think they used Okta, but I'm not certain about it. I have some demos from a long time ago, but I think Okta is for SSO.

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

Private Cloud

Amazon Web Services (AWS)

We have integrated with IAM. We haven't used it in production now, but we are still in the research and development stage. We are planning to use the Amazon EKS hybrid solution by using our own data center virtual machine on our Amazon EKS clusters. A hybrid cluster would be a great solution for us since we have many resources here, and we want to utilize our cloud service. We are still in research and development solution. The only use case I can remember integrating IAM with Amazon EKS is the hybrid work for nodes.

We wanted to easily integrate our on-premise nodes with Amazon EKS to fully utilize the cloud service with our already persistent on-premise nodes. The major use case was that we wanted to host calls where the latency has to be in one digit. We can't have a call here in Mongolia jump from the Hong Kong AWS server and jump back to us. That would be a terrible experience for our users. We would have to implement the one-digit latency solution within our country, so we have to utilize the on-premise data center nodes. That was a bit of a challenge for us. Other than that, it's usually great.

For scaling our application, ensuring high availability and cost saving with Amazon EKS, the automatic load operation, no maintenance, and all features are really nice for our business.

In our old cluster, we were using on-premise Kubernetes. We had some downtimes here and there, with downtime being a monthly occurrence to our business. When we switched to Amazon EKS, we haven't faced any downtime in two years so far. That means no stop business growth for our type, and we can continue focusing on our business agility. The maintenance, configuration, and maintenance of our cluster has never been needed. We can update our Kubernetes cluster versions by just clicking one button. Before that, it was a long and tedious task. We would have to do it during nighttime operations. Operations are minimized and downtimes are non-existent now. Adding nodes and removing nodes are automatic so we could save costs there too.

The application supply chain integration has never been easier with Amazon EKS. We have integrated Amazon EKS into the CICD pipeline. Our developers are just pushing our code to our repository, and a few minutes later, it's deployed in Amazon EKS.

Mostly, it's just minimizing the manual preparations and increasing our business time with Amazon EKS so we can focus more on improving our applications and researching new ways to improve our business side. This means less time on the system side manual configuration and more time on making our applications better for our users.

We haven't fully utilized self-healing nodes in Amazon EKS yet. The self-healing nodes are still in our research and development stage. It is new we are using in production clusters.

We have been working with Amazon EKS for two years in our company now.

The Amazon EKS itself is great. We haven't had an issue with that.

We asked customer service regarding a wrong charge on our billing account, but I haven't initiated a request ticket, so I'm not very familiar with it. Our DevOps team had started the process. We reached out to them before.

It was really positive. The customer support was nice, informative, and very helpful.

Positive

I think it's reasonable. The EP two nodes are a bit expensive on the side. Other than that, Amazon EKS is pretty reasonable for its price.

We researched the pricing and how much it would cost in a month, so we are aware of the pricing.

Other than Amazon EKS, there's also GKE, the Google solution, and the Microsoft Azure solution and also OpenShift. We considered Amazon EKS because it's the most popular and widely available one. We opted for Amazon EKS because most of our engineers are familiar with the AWS environment.

We will apply it because it's easy to get out. We can easily integrate it in your application. It also has the most documentation out there. I would advise it.

Currently, we are just following the best practices with Amazon EKS. We follow the usual best practices or workflow with Amazon EKS and load balancing.

In comparison, the latency is a bit high with Amazon EKS. When we were researching about a year ago, Google offers almost forty milliseconds delay to Mongolia, as Amazon EKS in Hong Kong offers sixty milliseconds delay. That was the only downside from not choosing Google over Amazon EKS. Other than that, Amazon EKS has a lot of services.

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

Hybrid Cloud

Amazon Web Services (AWS)

My usual use cases for Amazon EKS are for my company's projects, as they instructed us to set up Amazon EKS and then deploy the applications.

I use Amazon EKS mainly for my company's projects, where we deploy applications according to company requirements.

The features and capabilities of Amazon EKS have proven to be valuable, as we use EKS in most of our projects. Our company has selected AWS as one of our three cloud preferences, which are AWS, GCP, and Azure.

The specific features I find most useful in Amazon EKS include the ability to deploy our applications directly using the pipeline file in YAML, the capacity to create multiple instances, and the capability to scale as per the requirement.

Amazon EKS's self-healing nodes help minimize administrative burdens in my organization by automatically creating a new node if any node crashes, allowing us to manage only the minimum and maximum nodes as needed.

To use Amazon EKS, we create the cluster first, and then we deploy the applications using the YAML file.

I have not used the automated patching feature for my Kubernetes clusters in Amazon EKS yet.

I think if new features, especially AI capabilities, are developed for Amazon EKS, it will enhance the product as it allows us to continually improve our applications.

I have been working with Amazon EKS for the past three years.

I participated in the initial setup and deployment of Amazon EKS.

My impression is that Amazon EKS is very stable and reliable as a product.

I have not noticed any outages, delays, or downtime with Amazon EKS; everything operates smoothly.

Amazon EKS is easy to evaluate in terms of scalability; we can auto-scale easily as needed.

I would rate the scalability of Amazon EKS as a nine out of ten.

I do not often communicate with the technical support of Amazon EKS as I have not needed their assistance.

For our work with Amazon EKS, we utilize the available documentation and guides, which are useful for understanding and starting with any AI tool or prompt.

I am satisfied with the documentation that Amazon offers.

Neutral

Amazon EKS was my first Kubernetes platform. Prior to that, I had only used Minikube locally, and after that, I have worked exclusively with Amazon EKS.

During the setup process for Amazon EKS, I set it up locally by configuring AWS config, and then I focused on the necessary setups like kubectl.

To start working with Amazon EKS, I first configure it with AWS, install kubectl, and then begin working after creating the cluster.

I chose Amazon EKS to work with because I have not yet started using GCP's or Azure's Kubernetes services. I have experience only with Amazon EKS so far.

I have only worked on one application in Amazon EKS, so I haven't fully developed it. I have only deployed the front end, and I think I need to gather more knowledge about EKS.

The interface of Amazon EKS is very good, but I prefer to use the CLI for creating clusters. I initially used the UI just once to understand everything before starting to create using the CLI only.

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

Public Cloud

Amazon Web Services (AWS)