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)

I use Amazon EKS for creating users, depending on the project I've worked on. I use it to update config maps and for role binding in the Kubernetes cluster. Additionally, I use it for creating namespaces and accessing different clusters, such as dev clusters.

Regarding integration with IAM in Amazon EKS, I use it primarily for creating IAM users and managing permissions for users.

While I cannot specify a single favorite feature in Amazon EKS, I particularly value the user creation and config map functionalities. Both processes are straightforward - creating users and updating the config map are easy tasks.

The main benefit of using Amazon EKS is that it makes work more efficient and enables faster delivery.

The main area for improvement in Amazon EKS relates to master node control. When setting up a Kubernetes cluster independently, you have access to the master, but with AWS, you do not have control over it.

The support team of Amazon EKS is excellent and very helpful. I have never experienced any issues with them.

Positive

We briefly used Google's solution before switching to Amazon EKS. After that brief period, we have exclusively used AWS.

For the initial setup of Amazon EKS, we typically follow established guidelines. In most cases, we are not responsible for creating it directly. We work through our Jira and Confluence systems, completing assigned tickets and projects rather than setting up the system from scratch.

The pricing of Amazon EKS varies depending on the size and specific requirements of individual companies or clients. Many companies choose AWS because of its competitive pricing. The prices are considered fair by most users.

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

Amazon Web Services (AWS)

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.

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

I use Amazon EKS for one of my customers when I am an independent contractor. They do video recording for events such as weddings, advertisements, and other occasions. They wanted to stream their content, and I advised them to use Amazon EKS as a good solution so they can easily ingest the raw materials, process it, do all the cuts using specific video software, and then publish it wherever they need.

The ease of implementation and integration was accomplished by writing some small scripts. I implemented workflows for data ingestion, sending it for cuts, and then directing it to the presentation layer. The simplicity of it was key.

The automated patching feature for the Kubernetes clusters provided valuable benefits through ease of maintenance and simplification of maintenance. I don't have to manually monitor or create any additional services for monitoring the patches; it's just there and does the work automatically.

From my perspective, integrating existing applications into a single workflow is beneficial for application development and application integration.

The workflows were straightforward, collecting data from raw recordings from cameras, putting them on cloud storage, ingesting them into video editing software, and going to a CDN for publishing.

About a year and a half ago, the cost was somewhat high. Though I wasn't directly affected as my customer paid for it, they complained about the billing. If they could reduce the price, that would probably attract more customers, especially from this industry, as they are rather small companies with limited budgets for such tooling.

I have been working with Amazon EKS for about a year and a half, with my first notes dating from March 2024.

I escalated a couple of cases to AWS support. I have mixed feelings about this as they were quite helpful, but the response times were quite long. It took them about five business days to get a response to my question, but when they replied, the response was very valuable and helped me.

I didn't notice any crashes, slowness, or performance issues with the Amazon EKS product. My client could have potentially experienced such issues while using it, but they never reported any complaints, so I don't believe there were any issues.

I would rate the tech support around seven or eight on a scale of one to ten.

Positive

I worked with container services about a year ago as part of my project at that time. I enjoyed using AKS, but I think its equivalent in AWS is better; it's more mature and easier to implement than AKS on Azure.

The best feature I found in Amazon EKS is ease of implementation. I'm not very knowledgeable about video software and had to learn it quickly for this specific project, and I found it very easy to implement. It probably took me a couple of hours to really understand it and learn how to use videos, and it was probably the easiest of all the solutions that I tried.

I use the DevOps server as software as a service on Azure. I didn't need to set any server for that; it was just there. I added it to my dashboard and started using it.

In terms of cost savings, time savings, and efficiency improvements, I've definitely seen returns on investment. Considering my rate and the couple of hours spent, rough calculations show around 30% return on investment.

The majority of my time setup cost was very affordable, taking just two hours. It was easy as I didn't have to worry about setting all the infrastructure underneath, just using what's there. This saved my time, allowing me to complete the project within several hours instead of days or weeks.

When I evaluated several solutions, Amazon EKS looked more intuitive to learn. I was prototyping for two hours each, and with Amazon EKS, I had this raw prototype running after around two hours. With other services, after two or three hours, I was still in the middle of my work with no visible effect, so that was the benefit.

I am working with a set of tools within the Azure toolbox. Azure is a huge collection of services with over 100 of them. I use virtual machines, Azure Functions for serverless processing, especially for creating APIs that do automated tasks. Additionally, I use SQL Server database and infrastructure as code, creating using Terraform, creating virtual private networks, setting up firewall rules to increase the security of my customer's solution.

I give Amazon EKS a rating of 8 out of 10.

Amazon Web Services (AWS)