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)

For Amazon EKS, the usual use cases I have been working with include many microservices where we cannot orchestrate in a better way in the ECS, which is an AWS native component. The major reason for moving to Amazon EKS is that if we have a microservice that takes more time to do the job, we need to return it while also running some other small microservices in parallel with that application, which we cannot do in ECS.

We moved to Amazon EKS where we have the feasibility to do parallel jobs with different microservices within the same pod, since we can run multiple containers in one pod. This helps us mitigate challenges in the company, and it works smoothly and fast, providing good performance and strong security. That has been our journey towards Amazon EKS across all customer platforms.

The most valuable feature of Amazon EKS is the add-ons service, which includes the Ingress feature that allows us to connect to both public and internal-facing load balancers. The best thing I have found is the management; using Rancher management, we can connect to Amazon EKS and manage the deployment from the UI without always needing to use the AWS console. We can create our own Rancher portal and directly manage the deployments and all other tasks from there.

Amazon EKS is a major tool for our application functionality and job purposes; it helps us at the orchestration level, allowing us to not worry about the entire deployment and service migration. We manage everything from Amazon EKS, and it's also very convenient to set up CI/CD deployment through GitHub. Additionally, we can utilize AWS native services such as CloudDeploy, so in both ways Amazon EKS has been convenient for running our applications.

I believe there is room for improvement in Amazon EKS, particularly regarding security; if Amazon EKS would provide more options for cluster-based security, it would be beneficial. Currently, it's completely managed by AWS, but I suggest that if Amazon EKS could allow monitoring of the backend of the nodes or workflows, it would greatly help users. Sometimes, AWS's shared responsibility model means that if any issues arise, the misconception lies with the users.

For instance, failures from containers running on nodes in AWS data centers can halt our workflows, especially when running in single availability zones. If AWS could enhance user interaction for improving security, it would be very helpful.

I have been working with Amazon EKS since 2017, which amounts to approximately eight years.

I have utilized Amazon EKS's integration with IAM through the service account, which is a great feature because we don't need to depend on storing secrets in Amazon EKS. We can directly use service accounts and rotate our tokens every 24 hours, which helps us achieve fine-grained access for both the user and the cluster-wise.

Compared to different cloud providers, AWS EKS pricing and licensing is absolutely reasonable and one of the best options available.

In terms of stability and reliability, I can say that among all options in the market, Amazon EKS is very reliable. I haven't experienced much downtime in the Amazon EKS cluster, so I can confidently say it is stable.

Amazon EKS has been quite scalable; people nowadays are moving to multi-AZ setups. When we choose Fargate, the beauty of Amazon EKS is that we can run multiple containers from different availability zones within the same pod. This is beneficial for availability and scalability because, using ReplicaSet, we can ensure that our containers remain at the desired count, automatically pulling new containers whenever one goes down.

I often communicate with Amazon EKS technical support, and my impression is positive. When I was initially setting up, I needed to understand a few things from AWS, and they provided substantial support, being very professional and helpful.

I had to address technical support when one of our nodes was suddenly terminated while utilizing a single availability zone, which caused application downtime and business disruption. However, AWS management tackled this situation very well by providing us with a solution that enabled us to shift to multi-AZs, as AWS guarantees 99.9% availability but acknowledges the need for users to avoid relying entirely on a single AZ.

Positive

I usually participate in the initial setup and deployment of Amazon EKS; I've done this in four projects, giving me good hands-on experience with Amazon EKS.

My usual deployment and initial setup process for Amazon EKS is straightforward. First, we need to spin up the cluster, which involves providing the cluster name, VPC details, subnet details, security details, and network mode—either AWS VPC or a customized network mode. There are several options, including attaching an IAM role and adding on features such as proxy connection and network protection. After spinning the cluster, we start the Kubelet client installation from where we can manage the cluster and begin deployments using YAML scripts and manifest workflows.

Recently, Amazon EKS launched an automated patching feature that allows us to schedule a time frame for cluster scaling up, down, and patching, which has been very helpful across all aspects.

I usually measure the impact of Amazon EKS on managing complex workflows by evaluating performance, specifically how the containers are available and performing. Based on application latency, we can determine that Amazon EKS performs well. We measure in this way because latency is the differentiator between every service; with ECS, latency can be slightly higher, which causes user difficulties when accessing applications.

Overall, based on everything I've described about Amazon EKS, I would rate this solution eight out of ten.

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

It is a managed service, a Kubernetes cluster, specifically for Amazon EKS. Whatever application is going to deploy on the cloud, cloud provided this solution, a managed service cluster, a Kubernetes cluster. In that scenario where we will use for seamless and zero downtime, we are using Amazon EKS.

The major advantage of Amazon EKS is that it is a managed service. Whatever error or downtime, if we are dealing with an on-prem Kubernetes, we have to understand the root cause. If the control plane is down, understanding and fixing takes time. But AWS provides a solution, Amazon EKS, where we are not worried about any control plane components, such as ETC, other API servers, etc. It is a significant advantage, as AWS continuously checks for problems. If they occur, they will fix them immediately. They will also configure the backup from the background. As an end user, we are not able to understand any kind of downtime. For us as end users, it is always working for the managed services.

When dealing with Amazon EKS, as an end user, we also configure the IAM policies, role, and responsibility for users managing the cluster and node cluster. The user-specific permissions determine whether they are able to deploy applications to the managed service, whether at root level, admin level, or developer level with view access. We make decisions accordingly and provide the IAM permissions.

We have RBAC and context, two major parts of the Kubernetes services that provide security and the authentication and authorization process. We implement context and RBAC to secure our Amazon EKS cluster.

Because it is Kubernetes, these services need to be integrated with the Kubernetes repository. ECR is a repository, an Elastic Container Registry. When creating or integrating any images with updated builds, we create updated Docker images, push them into ECR, and integrate our Amazon EKS services with ECR. It syncs with that repository, so whenever it identifies new Docker images, it will pull and deploy them into the Amazon EKS cluster.

When setting up an Amazon EKS cluster, we define the number of nodes with minimum, actual, and maximum parameters. For example, with a minimum of two nodes for normal load, only two nodes will always be running. If it identifies increasing server load, it will automatically increase to two more nodes if we have set the maximum to four. In the Amazon EKS cluster configuration background, we specify load thresholds at 70% or 80%. It will identify that and increase or decrease nodes accordingly. If load changes persist for more than 15 minutes, it will take appropriate action. We define an auto-healing process there.

The automatic patching is valuable because it is a managed service. Whatever patching is required, the vendor itself will provide communication. If we provide confirmation, we will provide the upgradation time window. AWS itself will do all kinds of patching during that specified window to upgrade the Amazon EKS cluster.

On-premises Kubernetes requires daily updates. With managed services, the Amazon EKS version upgrades are very helpful. The managed services handle the control panel upgrades, and they will upgrade node dependency software by default. Sometimes we will check if the node dependency software needs manual updates.

The major advantage is reduced setup time. The Amazon EKS setup is much simpler compared to on-premises AKS setup, where the control plane configuration is very difficult. It is very flexible as we configure the required number of nodes into Amazon EKS, and it starts working. We get high availability and scalable architecture. Even if the control plane has issues, AWS will understand, control, and take immediate action.

We only need to ensure that Docker images are pushed to ECR are correct, and Amazon EKS will handle the deployment. The major advantages include reduced time, high availability, and scalability. From a security perspective, AWS has multiple security layers. We also implement IAM roles, different ILBs, ingress controllers, and multiple security features. CNI implementation on top of Kubernetes is also available.

The costing perspective could be improved. With normal on-premises servers using Kubernetes services, the costing might be slightly higher compared to other Kubernetes vendors. If the pricing becomes more comparable and they match other vendors while providing more flexibility, it would be more advantageous for AWS.

The solution has been in use for more than four years.

The deployment has been confirmed as successful.

There have not been any gaps felt between Amazon EKS and AKS. Whatever capabilities AKS has, Amazon EKS has similar capabilities feature-wise.

The service is very straightforward. The official manuals provided are very helpful. We have not experienced any discomfort or hidden aspects.

Whenever we face challenges or have questions about different platforms or tech stacks, or if we need to verify support or integration possibilities, we raise a ticket. They will set up a call, guide us, or provide solutions regarding integration with AWS or Amazon EKS.

The service is very professional, rated five out of five. When we raise requests, they follow their process and are always available to support us.

Positive

Having worked on both AWS and Azure, AWS is very straightforward and helpful to implement, both as a support engineer and as a developer. The AWS support team is very knowledgeable and helpful. When requests are raised, they take immediate action. It is recommended that everyone should consider AWS.

Our organization maintains a strong team. For major projects, we first work on the architecture perspective. With well-designed architecture, 90% of potential problems are prevented. Being a managed service, we focus on security and managing node services, along with the application perspective.

We are not concerned about the Amazon EKS cluster setup as it is a managed service. We only need to add nodes and utilize the features Amazon EKS contains. This reduces our effort and is very helpful for our organization.

The reviewer rated Amazon EKS 10 out of 10.

Public Cloud

Amazon Web Services (AWS)

In my recent project, I have used Amazon EKS to deploy and scale machine learning and generative AI applications, containerizing LLM-powered APIs with Docker and deploying them using EKS for high availability and scalability. I also integrated the CI/CD pipelines and GitHub Actions to automate deployments into EKS clusters, leveraging IAM roles for service accounts, KMS encryption and VPC isolations for security. I used CloudWatch, Prometheus, and Grafana for monitoring, and Amazon EKS allowed me to build scalable, compliant, and enterprise-ready AI services without worrying about managing Kubernetes manually.

When it comes to the best features of Amazon EKS, there are some measurable properties such as variables we can feed into the model to help with market predictions. For example, for a credit risk scoring model, features might include transaction history, credit score, and income repayment. Selecting, cleaning, and transforming raw data into meaningful features to improve model performance will improve the precision and recall of the model significantly.

Amazon EKS has many powerful features that abstract the complexity of Kubernetes. Simple networking can be used for VPC and CNI, such as service meshes. However, EKS upgrades can lag sometimes when Kubernetes versions move quickly, delaying the adoption and adjustment for the latest features. I also see opportunities for better out-of-the-box monitoring, as integrating Grafana and Prometheus requires effort. Amazon EKS itself would make it easier to unify traces and metrics and allow for secure cross-cluster communications.

The initial setup in Amazon EKS is complex, especially compared to services such as ECS and Fargate, which I worked with in my US Bank project, involving VPC networking, IAM roles, or node groups. However, once set up, the deployment becomes easy. Using infrastructure as code, such as pipelines, I usually automate cluster creation with Terraform and integrate GitHub Actions. We use standardized Kubernetes manifests that make spinning up and scaling clusters much easier, so while the initial setup is complex, networking and IAM integrations make deployment and scaling smooth and easy to handle.

I have been using Amazon EKS for four years, and I have used it in my Accenture projects too, so I have good experience with Amazon EKS.

Regarding the support team from Amazon, I have some experience working with them, as most of the support cases I raised were related to cluster upgrades, networking issues, and IAM permission troubleshooting. In my project, we ran into deployment issues with EKS clusters and network failures across multiple nodes, and the support team helped us identify the VPC subnets.

Regarding the support team from Amazon, I have some experience working with them, as most of the support cases I raised were related to cluster upgrades, networking issues, and IAM permission troubleshooting. In my project, we ran into deployment issues with EKS clusters and network failures across multiple nodes, and the support team helped us identify the VPC subnets.

Positive

Before moving to Amazon EKS, I worked on different solutions such as Amazon ECS, which provides elastic containers that are more flexible for fine-grained scaling, making them a better choice. I have also deployed serverless APIs such as AWS Lambda and API Gateway for the LLM interface, where Lambda's runtime and cold starts differ. On the Azure side, I have used Azure Kubernetes Services.

The initial setup in Amazon EKS is complex, especially compared to services such as ECS and Fargate, which I worked with in my US Bank project, involving VPC networking, IAM roles, or node groups. However, once set up, the deployment becomes easy. Using infrastructure as code, such as pipelines, I usually automate cluster creation with Terraform and integrate GitHub Actions. We use standardized Kubernetes manifests that make spinning up and scaling clusters much easier, so while the initial setup is complex, networking and IAM integrations make deployment and scaling smooth and easy to handle.

The pricing of Amazon EKS varies; EKS pricing is somewhat affordable for small clusters but gets expensive at scale. If we manage it carefully, the control plane can be easier to handle. For bigger clusters, it will be somewhat expensive, but smaller clusters can be affordable depending on the choice.

I would recommend Amazon EKS to other people because it is useful, and I believe they will benefit from using it. Based on my extensive experience with the product in my recent project, I rate Amazon EKS 9 out of 10.

I am an end user of Amazon EKS. As a software engineer, we are using Amazon EKS as a platform for deploying our applications.

The most valuable features of Amazon EKS that I have found include scalability, simplicity in operations and management, and some great features for optimizing cost. Those are probably the main advantages.

Speaking about scalability, it basically means that we are able to scale our workloads according to our needs, which is useful. Regarding cost optimization, sometimes infrastructure in AWS might be a little bit expensive, so having some functionality to get it more manageable and to have some cost reduction solutions in place is always useful. Additionally, not only Amazon EKS but the Kubernetes platform itself is a very popular platform, and many developers are familiar with it, making it convenient for the company to use. It is much easier for our developers to get any information about solving problems and developing applications because information is widely available.

I have seen a positive impact from Amazon EKS for my organization since deployment; it provides a very robust and cost-effective platform for deploying our applications. The Kubernetes platform is well known and widely available, which means there is a lot of information about it. Since it is a manageable solution, it removes a lot of the burden and headache of managing our own cluster on bare-bone hardware. While we do not rely heavily on Amazon infrastructure, I understand that if someone were to rely on it heavily, it would be much easier to integrate with Amazon EKS.

In my opinion, Amazon EKS could improve its plugin management; while Amazon offers some improvements, they often come at an extra cost. Compared to Google, for example, having the same cluster in Google Cloud is much easier because it hides all the complexity of managing Kubernetes add-ons and plugins. EKS is improving in this area, but it could still be smoother and better. Upgrade management is also a constant concern because EKS frequently forces users to upgrade, which can be inconvenient due to the risks involved in introducing something new, especially at the platform level.

I have been working with Amazon EKS for probably two or three years.

It is hard to say how Amazon EKS's self-healing nodes help me minimize administrative burdens since we have not had any issues with them in a Kubernetes environment. The Kubernetes platform provides capabilities to replace nodes, and everything just goes smoothly under the hood.

We do not use Amazon EKS's automated patching feature for our Kubernetes clusters.

Amazon EKS's support for AWS tools integration has not influenced my application development and management process much; we do not rely on any specific AWS features.

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

I have reached out to Amazon EKS support a few times in my previous project where we had a subscription plan for support, but in the current project, we have no business support.

My impression of Amazon EKS support is generally positive; my experience depends on the person on the other side, but the vast majority of cases involved very professional and skilled engineers. However, there was one instance where I was not completely satisfied with the answers received. Overall, I would rate them eight out of ten.

Positive

Before Amazon EKS, we used a different solution, specifically ECS and Elastic Container Service, and we still use it alongside offerings from other cloud vendors such as Google, as well as self-hosted clusters.

I personally participated in the initial setup and deployment of Amazon EKS. The setup process for Amazon EKS is fully automated, as we use Terraform for bootstrapping and managing our infrastructure, so there are no issues at all. Everything was straightforward with no challenges. The only thing I can remember, which is relevant for the previous question, is that when creating a Kubernetes cluster in the AWS web console, it does some changes under the hood, such as creating a default role for authentication. However, doing it through command line tools or automation with Terraform requires some manual steps, which is not very convenient.

I would like to optimize the Amazon EKS setup process in the future, but we probably will not take action because creating a new cluster is a rare task for us. Spending an extra 15 minutes on manual steps probably would not be worth the effort of full automation.

I do not have any metrics to measure the impact of Amazon EKS on my organization's ability to manage complex workflows efficiently.

I am aware of the pricing of Amazon EKS. I do not consider Amazon EKS an affordable solution; it is not cheap for sure, but it depends. For a small project, such as a personal project or a proof of concept, the cost is fairly noticeable. However, for a full production setup, I think the cost is manageable.

The main advantage for us in choosing Amazon EKS is the AWS infrastructure and the cloud ecosystem, including databases and compute instances, which is probably even more important than Amazon EKS itself.

I have not utilized Amazon EKS's integration with IAM.

I do not really integrate Amazon EKS with other AWS services; our current application would work with any Kubernetes platform, whether it is Amazon EKS, Google Cloud, or any other self-hosted Kubernetes cluster, most likely with some minor tweaks.

We do not use any specific Amazon EKS APIs or functionality, so I do not have anything to share about integration capabilities.

My personal rating for Amazon EKS is six out of ten, as it really depends on personal preference.

Public Cloud

Amazon Web Services (AWS)

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)

We are the end user of Amazon EKS. I will provide context for clarity. In my previous project at Johnson & Johnson, we had assets including Jenkins running on Amazon EKS cluster. This is how we were using it as an end user.

One of our use cases for Amazon EKS involved Jenkins running as a pod. We had an EBS volume in AWS that handled all storage-related tasks, while Amazon EKS managed the heavy lifting of ensuring Jenkins was always operational. Additionally, we integrated Prometheus and Grafana for data and metrics, which also ran as pods on Amazon EKS.

We have also utilized Amazon EKS's integration with IAM.

The most valuable aspect of Amazon EKS, from my perspective as someone who has worked with on-premises solutions, is that it eliminates manual setup requirements. Amazon EKS handles everything automatically, removing the effort of manual configuration that is necessary with on-premises solutions.

The auto-scaling capabilities are particularly notable. Based on the nodes configured, it automatically scales according to minimum and maximum node parameters. The load balancing functionality is another significant feature that makes Amazon EKS exceptional.

Amazon EKS's self-healing nodes have significantly minimized administrative burdens in our organization. This functionality stems from the auto-scaling capability of Kubernetes. From the Amazon EKS perspective, it provides features for setting up nodes, giving users and administrators the flexibility to ensure applications running on those nodes remain operational.

From a DevOps engineer's perspective, the IAM roles system could be improved. When creating a cluster, we need to create and assign roles. If this process could be simplified, especially for users with limited AWS knowledge, it would be beneficial. Currently, users need to understand IAM fundamentals, how it works, and how roles and users are defined.

It would be helpful if Amazon EKS offered ready-made templates, similar to AWS's default VPC option. This would make the service more accessible to new users while maintaining its functionality for experienced users.

We have not encountered any issues with Amazon EKS's automated patching feature for our Kubernetes clusters.

We have been using the Amazon EKS cluster since August 2023, which is more than two years.

For the initial setup, since we were a private organization, we had to establish the VPC, ensuring all due diligence with private and public subnets and internet gateways from the network standpoint.

When launching our Amazon EKS cluster, we had a dedicated cluster that needed to be bound with EBS to manage volume requirements. This setup supported our Jenkins implementation, followed by other tools such as Prometheus, Grafana, and deployments managed by Helm.

While the process wasn't entirely straightforward, requiring prerequisites such as IAM knowledge and strong understanding of Kubernetes, the managed service aspect of Amazon EKS makes it significantly easier compared to on-premises solutions.

Amazon EKS has proven quite stable. We haven't faced any challenges, and it consistently delivers on its committed SLA. There haven't been any bottlenecks in terms of reliability.

In terms of scalability, Amazon EKS deserves a perfect score. However, regarding storage, we must rely on services such as EBS, considering the ephemeral nature of pods. The load balancing capability and scalability are excellent. Regarding pricing, based on experience, Azure Kubernetes Service (AKS) offers slightly better pricing compared to Amazon EKS.

Our interaction with Amazon EKS technical support has been primarily during our disaster recovery (DR) region setup. While exploring options for potential Amazon EKS downtime scenarios, we found Velero to be the only backup option, which is both overwhelming and complicated to set up.

Our interaction with AWS customer support has been minimal because operations ran smoothly. When we did interact with them regarding organizational issues, they were courteous and resolved problems promptly. Based on these experiences, the technical support deserves a rating of 9.5 out of 10.

Amazon EKS was straightforward to set up. I personally participated in the initial setup and deployment of Amazon EKS.

Amazon EKS's support for AWS tools integration has positively influenced our application development and management process. In 2023, when Johnson & Johnson segregated to form Kenvue, our team was responsible for building the entire DevOps infrastructure.

For any startup implementing Amazon EKS cluster for infrastructure or DevOps needs, the solution is excellent. It minimizes configuration time and offers a user-friendly experience that allows even less technically skilled individuals to complete basic cluster setup tasks.

Our entire Jenkins pipeline is fully onboarded on Amazon EKS cluster, which we use as a fully managed cluster for our CI/CD workflow. End users, unaware of the backend operations, benefit from Amazon EKS's management of scalability and auto-scaling capabilities.

I would rate Amazon EKS 8 out of 10. While it excels in usability, scalability, and high availability, there is room for improvement. The addition of ready-made templates, similar to EC2's default security group feature, would enhance the user experience for newcomers.

Integration templates for new users would be a valuable addition to the service.

Private Cloud

Amazon Web Services (AWS)

We have been working on a use case where we need to deploy an application in Amazon EKS, which is a Kubernetes cluster. Kubernetes is a managed service provided by Amazon, and if we want to deploy any applications in Amazon EKS, such as application A, I want my application A to be more scalable, more tangible, and I want to deploy this in an Amazon EKS cluster. Then I check for any open source Helm charts, configure them, and deploy that Helm chart in the Amazon EKS cluster. This is how our day-to-day work goes. In general, we also deploy applications such as Apache Spark in the Amazon EKS clusters.

The features of Amazon EKS that I find most valuable include IRSA and IAM Roles for Service Accounts. While creating Amazon EKS clusters, Kubernetes offers a feature where we need to create an OIDC provider. Once configured, the authentication and authorization in the Kubernetes cluster is done by service accounts. Through the concept of service accounts, all the pods utilize IRSA, which is called IAM Roles for Service Accounts. By integrating AWS IAM roles with Amazon EKS service accounts, we can leverage other services from Amazon EKS. For example, if we want to access S3, Secrets Manager, or EC2, the concept of IRSA helps us integrate with external services of the Amazon EKS cluster easily. Additionally, Amazon offers Karpenter for scaling workloads and minimizing billing, along with managed node groups and advanced scheduling to manage our pods on different node groups.

To measure the impact of Amazon EKS on my customers' ability to manage complex workflows effectively, scaling in and scaling out is one of the key aspects for us. Since all our workloads are batch workloads that are intangible and unpredictable, we cannot keep nodes stale 24/7. Accordingly, scaling is of utmost priority. The appropriate node must spin up based on the workloads created at a given time, and pods should schedule on that node so that workloads run. For instance, if there are no workloads, there is no reason to maintain 100 nodes in the cluster, so scaling in and out is essential for not wasting resources or budgets.

One area of Amazon EKS that could be improved in the future is related to the behavior of the cluster autoscaler. We need enhancements so that scaling in and scaling out happens more effectively. Currently, the cluster autoscaler lacks visibility on the Kubernetes labels of a node group. The cluster autoscaler should at least be able to check the labels of the Kubernetes nodes, which is a necessary feature.

My experience with Amazon EKS is three years, and it has been very interesting to understand and easy to collaborate with other AWS services. It has been good working on Amazon EKS for the past three years.

Initially, I did not face challenges with the deployment of Amazon EKS, but I was not very familiar with Kubernetes initially, so it took me some time to understand Kubernetes first. The platform could be anything, including EKS, GKE, or AKS, but understanding Kubernetes was the first step necessary. After gaining familiarity with Kubernetes, Amazon EKS provided me with a good platform to work on, and I later cleared my CKA certification with a 95 percentile.

My impression of how stable and reliable Amazon EKS has been for me is positive. The upgrade process is also very fruitful, happening swiftly and without hassle or issues, so I have not faced numerous challenges. Moreover, the control plane is quite stable in Amazon EKS, and I find it to be 100% available.

Self-healing in Amazon EKS refers to what happens if any node becomes unreachable.

In our case, while I am not much sure about self-healing nodes, we utilize the cluster autoscaler in Amazon EKS. If any node is not ready, the cluster autoscaler ensures that it is removed from the AWS auto-scaling group and replaces it with a new node in the cluster.

My interaction with technical support and customer service at Amazon has been generally helpful, but they sometimes do not provide direct solutions. They tend to divert the conversation before giving a solution, which would be easier if they provided direct answers.

Once, we faced a situation where an EC2 instance got deleted due to unforeseen reasons. We reached out to support and inquired about the possibility of restoring our instance. They informed us that there was no possibility to bring it back, which felt like a dead end. I believe there should be a recovery solution available for at least a few hours so that we might bring it back; instead, we had to start again from scratch.

Positive

I usually participate in the deployment and setup of Amazon EKS. We create Amazon EKS clusters from scratch, deploy applications, and integrate them with all the AWS services.

Within the last 12 months, I have only been working with Amazon EKS. Currently, I have not been working with anything else other than Amazon EKS.

For the automated patching feature of Amazon EKS, we currently use EKS baked AMIs, which are straightforward to integrate with the Amazon EKS cluster. If we want to add additional packages or anything by boot time, it is very simple to do so while working with Amazon EKS. We can utilize a user data script to perform any patches, software upgrades, or installations, all accomplished at the instance creation time using EC2 node templates.

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

Public Cloud

Amazon Web Services (AWS)