Amazon EKS Reviews

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.

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

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

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

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

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

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

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

Hybrid Cloud

Amazon Web Services (AWS)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

I am satisfied with the documentation that Amazon offers.

Neutral

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

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

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

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

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

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

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

Public Cloud

Amazon Web Services (AWS)

There are migration projects where we need to migrate some on-premise services to Kubernetes. In that case, we have used Amazon EKS to migrate our workload. There are two production services that we need to deploy on the cloud, so we chose to use Amazon EKS to deploy them on the servers.

There are multiple node clusters that we have within Amazon EKS. We have different node groups that we have used. Some of them are high performance, some have high-speed hard disks, and some have high CPU. There are multiple node groups that we have provisioned and also enable the scaling within the pod level and within the cluster level. There are multiple features that we have used along with node management.

For streamline, we need to apply GitOps within Amazon EKS. Whenever there is a commit in the deployment-related stuff, we need to deploy the new image on the image repository, and from there, we need to update the kubectl YAML files with the new image tag. We can also choose the Helm charts based, and we can also choose Argo CD for the automated deployments.

We have implemented two things with Amazon EKS. First of all, OIDC-based connectivity between the AWS services to the Kubernetes workload. Additionally, we implemented RBAC. We have used RBAC to provision IAM users to have proper security and a constrained environment so that read-only users can only read the things.

We have used Amazon EKS Anywhere for on-premises deployments, and within Amazon EKS, it has an air-gapped environment where we can deploy the things and manage the local type of Kubernetes.

Managing the production workload in Amazon EKS is highly valuable. It has many features, for example, self-healing, automatic deployment, rollouts, and better management. It is an Amazon managed service, so we need to just focus on the cloud itself.

We have installed Prometheus and Grafana within our Amazon EKS, and we have used DataDog operators as well to have proper production workload management and monitoring management system. We can see the logs, alerts, and everything related to it. We have integrated Slack and email addresses through SES. This is how we are monitoring our production workloads and get alerts based on problems within our production.

The main benefits from using Amazon EKS include it being a well-tested product that we can use to deploy our workload. Its management system is very efficient. We can deploy things very easily and resolve our issues efficiently. It has deep AWS integration and a managed control plane. It has built-in IRSA-based security model for IAM roles. We have flexibility and portability. We can use Helm, Argo CD, Flux CD, Istio, and Linkerd. We can use multiple EC2 machines, such as spot instances and Graviton-based instances that are GPU-powered. These features help us use Amazon EKS for our production environments.

I would appreciate seeing integration between the other services in Amazon EKS. For example, there are now more managed Prometheus and managed Grafana services available last year. I would appreciate knowing more about how AI-based services get integrated with Amazon EKS and what kind of AI automation, healing, or troubleshooting services Amazon will introduce in upcoming releases.

I have been working with Amazon EKS for three to four years.

The setup of the Amazon EKS environment is quite fairly simple, and we can easily automate them using Terraform as well.

Once everything is set and done, there is no maintenance required, which is a very good point.

I did not see any crashes, downtime, or performance issues with Amazon EKS.

We have enabled the cluster-level enablement and auto-scaling in Amazon EKS, and that helped us significantly. Whenever we have peak time, it will automatically manage the node for us, and there are more nodes to manage our workload.

For a few of the cluster upgrades that got stuck, we connect with Amazon tech support, as we have business support with Amazon. We connect with them, and we figure out the problem. They help us to troubleshoot the issue, and we run commands related to Cordon or Taint. With this, we complete our upgrades process.

On a scale of one to 10, I would rate the technical support and customer service of AWS as eight to nine. They are very technical, and they can easily fix things within 20 to 30 minutes.

Positive

I worked with on-premise Kubernetes, and I also worked with Azure Kubernetes, AKS.

I have worked extensively with Amazon EKS, and I have automation scripts ready. Whenever a new client comes to me, I request them to see my previous portfolio, and I show them my Amazon EKS work and how quickly I can set up their Amazon EKS and run the CI/CD so that their workload can get migrated to Amazon EKS. It is quite easy for me now to advocate for Amazon EKS.

We have a big business up and running in Amazon, and we have different AWS accounts: dev, test, and prod. Based on that, there is a root account who is paying the prices for us. The workload and the profit that we are getting, we are satisfied with what it is offering.

The pricing of Amazon EKS depends upon the node group that we are choosing and what kind of auto-scaling that we have implemented. It is totally dependent on those things, including what kind of network bandwidth that we are consuming.

I find the pricing of Amazon EKS reasonable. We actually are going to pay a yearly advanced payment, which helps us save on cost.

Amazon EKS has strong integration with its services. In Azure Kubernetes, it does not have strong, deep integration with its services, for example, Active Directory, Azure Registry, Azure Monitor. Both have their managed control plane and node management. Amazon EKS has a different pricing model - it is per cluster control plane level, whereas AKS is not on the control plane fleet's history. Regarding security, Amazon EKS provides IRSA-based, IAM role-based security, whereas AKS provides directory, Azure Active Directory.

It is a very well-known product, and there are many clients in the market who are using Amazon EKS, so it is the best service offered from AWS. I rate it a nine out of ten.

At the moment, whatever is required in Amazon EKS is already there.

Public Cloud

Amazon Web Services (AWS)

I am currently using Amazon EKS to host our applications to provide scalability and security.

Amazon EKS is providing auto-scaling, which is one of the features that everyone is moving to because it eliminates the need for manual deployments on EC2 machines or on Docker.

Kubernetes manages all those things, which is why people are moving to Amazon EKS. For Kubernetes as a project, it can be difficult to manage, but that problem is solved by Amazon EKS so I just need to think of our application rather than the infrastructure, and AWS manages all the infrastructure.

Because of Amazon EKS, if I do manual deployment on Docker and my particular container fails, I will not know the reason. However, Amazon EKS automatically restarts that particular container or stops it and creates a new one, switching the traffic accordingly.

This is why Kubernetes provides a better experience. Amazon EKS provides scalability, which is one of the features everyone is using. In case of high traffic, it automatically scales the nodes and pods, and we can scale it horizontally or vertically.

The authentication process means that with IAM policies, I am giving the least privilege access so only particular persons are able to manage Amazon EKS clusters. Everyone does not have access, which creates a kind of zero-trust security.

In a minor enhancement sense, I just needed some documentation on that, which has already been provided, but in simple English language that is easy to understand for freshers as well.

I also needed to have some infrastructure to do some practice sessions before we could move on, because the pricing of Kubernetes and Amazon EKS is too high. For some people, it is hard to get hands-on experience with those.

I have been using Amazon EKS for almost 1.5 years since I joined the cloud infrastructure team.

I would rate Amazon EKS around 9 out of 10 for stability. It is stable.

I did not need to communicate with the technical support of Amazon EKS yet. I have not communicated with their support specialists for Amazon EKS, but I did for other things.

Before Amazon EKS, I used manual deployments such as getting the code and running those on servers. Then Docker containers came into place, running code on Docker, followed by using ECS, and then Amazon EKS came into play. It was a logical update that I chose to go with.

I participated in the initial setup of Amazon EKS in the deployment process at my previous organization. For the initial setup, there are types of deployments for Amazon EKS cluster. Via the console, it is somewhat difficult, but via CLI, it is easy. You just need to set up AWS CLI and configure it, and then a simple command is AWS EKS CTL create, and we can create our Amazon EKS clusters. It is straightforward and not complex.

When purchasing Amazon EKS service for my application, if I have only one or two pods, I need to pay 75 dollars per month for that control plane regardless of what I am hosting, which can be challenging for small-scale companies. For small-scale companies, it is a challenging situation.

Let me provide some additional context. Jenkins is one tool to consider.

AWS DevOps is also available. For monitoring, Grafana and Prometheus are options. There are also some open-source tools that we are working on, such as Signoz.

Microsoft Entra ID is one of the products which we are using. For AWS, we are using AWS ECS, Amazon EKS, IAM for authorization and authentication purposes, and databases. All the services which are on AWS are being utilized.

Amazon EKS is different from Kubernetes because it is a platform built on Kubernetes but managed by AWS. Amazon EKS is already dominating the market more than others, so there is no enhancement from my side.

I utilized Amazon EKS's integration with IAM and OIDC. IAM roles have provided the capability to give permission to Amazon EKS that this particular Amazon EKS is able to access particular services such as the S3 bucket, which is one of them, and RDS, which is a database. We are providing roles to Amazon EKS clusters so that on our behalf, it can access these particular things. By that, they can access the database and objects in the S3 bucket.

I am not currently using Amazon EKS's self-healing nodes. In another organization, we are not on Amazon EKS.

For the nodes, I can tell that it provides auto-scaling to minimize and maximize the number of nodes as traffic comes. By that, the pods will run on those, and if there is any failure on nodes, it gives another node.

I would rate this product a 9 out of 10 overall.

Public Cloud

Amazon Web Services (AWS)

We use Amazon EKS mostly for deploying production workloads, and there are multiple AI models that we run on Amazon EKS.

My favorite feature of Amazon EKS is the ecosystem that it provides, including the integration with S3, along with EBS, and the networking that is smooth to run Kubernetes.

I have experience with Azure, and in comparison to Azure, a downside of Amazon EKS is that even if you want to deploy a dev workload or do some experimentation, we have to pay the charges for the control panel with no free option.

Additionally, I have faced many issues while configuring the node groups and the whole configurations; bringing up the nodes was a bit hectic, and I was not able to determine which node was failing and for what reason.

Specifically, the pricing for the control panel of Amazon EKS is hefty, and there is no cost-cutting that can be done on that side.

I have been using Amazon EKS in my career for four years overall.

Amazon EKS is pretty stable, and I have not seen any lagging, crashing, or downtime.

Amazon EKS is good in terms of scaling.

I have contacted technical support and customer support for Amazon EKS.

Positive

I have used Azure EKS, Civo, and also experimented with GCP as alternatives to Amazon EKS. If I have to rank between all three of them, GCP comes at number one, Amazon EKS comes at number two, and Azure EKS service comes at number three.

On the costing part of Kubernetes, Azure is beating Amazon EKS since I can do some experimentation without paying for the control panel; I can just pay for the node groups, which is an area where Amazon can improve.

From my point of view, the initial deployment of Amazon EKS is difficult.

I had to configure many components, such as IAM policies and other things; it was not a simple click-through process. The major issue is that there is no single point where I can see all the logs; while there is CloudWatch, it is not easily accessible, and you have to go through a hectic process to search and find information. There is nothing where you can go and click to get all the logs in a single place.

Amazon EKS requires maintenance on my end to continue functioning; we have to do upgradation from time to time since every Kubernetes version is only valid for one year.

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

Public Cloud

Amazon Web Services (AWS)

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 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 the usual use cases of Amazon EKS, we have been running different kinds of servers, such as web pages, and we have also used it to provide the SaaS solution for the end customer, delivering software as a service to the end customers. Basically, I deal with apps, SaaS applications, and websites.

We don't use Amazon EKS internally for us; we usually provide the service to others for their solutions.

The most valuable capability of Amazon EKS is managing the management portion of Kubernetes, which is the best thing that we get from Amazon EKS. Even though we have to upgrade it every six to seven months, it provides all the things required for us, so if a person knows how to install it and make use of it, that's all that's needed for using Amazon EKS.

Regarding self-healing nodes of EKS in minimizing administrative burdens for my customers, I appreciate that this feature allows nodes to try to heal themselves, which is a good feature. However, I haven't used this feature often, but having the service's ability to find and heal themselves or replicate is a good option for Amazon EKS to maintain high infrastructure uptime.

The area of Amazon EKS that could be improved is the development cycles because every six months a new version of Kubernetes is launched. Working in the infrastructure, I have found it quite difficult to keep up with infrastructure updates and new versions. Migrating the whole infrastructure from one Amazon EKS cluster to another is quite cumbersome, so if possible, version management should be made much easier than it is now, perhaps with some option to deploy code using blue-green updates. Creating a clone of the current infrastructure, updating it to the latest version, and terminating the old infrastructure would be a great enhancement.

I haven't used Amazon EKS's automated patching feature, but I believe it involves directly upgrading the AMI versions remotely or from the Amazon EKS dashboard. I understand it is a good feature, but I haven't used it yet.

I have been working with Amazon EKS for seven years in Kubernetes only, and I would say four years in Amazon EKS specifically.

My experience with the deployment and initial setup of Amazon EKS is usually straightforward. If you have the right Terraform code or the right knowledge, you can create it from the console or using Terraform or other tools; I don't find difficulties in starting a Kubernetes cluster. However, using the right principles or tools together with Amazon EKS may be challenging.

In terms of stability, Amazon EKS is pretty good. I don't encounter issues with stability if I use the right methods of deployment. For instance, using spot instances that are inexpensive can lead to downtime if not managed correctly.

My experience with customer service and technical support of AWS for Amazon EKS has been generally positive. Earlier, I was in developer support where the response time was maybe three to four hours after ticket submission, but I was able to resolve most problems with their support. I don't have any complaints.

I would rate technical support for Amazon EKS at an eight out of ten based on my experience with the developer support.

Positive

I have been using Amazon EKS for four years. In addition, I have used other solutions.

The integration of Amazon EKS with IAM is easy; if you have the right policy in place, you can create a role from the policy and then apply it to the application that you are using. It provides a way to use IAM to provision the software and infrastructure portions, as well as integrating application users into AWS IAM, making it very easy to implement if you know how to do it.

The influence of EKS's integration with other AWS tools on application development and management processes is significant; EKS itself is just the infrastructure. Application development requires the right tools with Amazon EKS, as it only provides a place to deploy things, and not the entire development cycle or management of workstations and servers. You must use something on top of Amazon EKS to fulfill the development cycle or CI/CD pipeline. Once the CI/CD pipeline is developed with Amazon EKS as the deployment platform, it becomes easy for developers to develop and test applications in the cluster.

I am not exactly sure about the pricing of Amazon EKS, but I think it is priced at the instance level, meaning EKS itself is not that high in price. However, whatever instances are used for Amazon EKS will determine the actual costs, particularly the traffic coming into the cluster.

Currently, I am not working with any software other than Amazon EKS, but we have plans to utilize some other applications, not just Amazon EKS, involving other services of AWS.

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

Public Cloud

Amazon Web Services (AWS)

We are currently using Amazon EKS as a production environment where we deploy multiple services because we serve banks using our services for identifying threat analysis and synthetic identity. Our main use case for Amazon EKS involves deploying our services based on scoring to determine whether a particular user is valid or invalid based on their social security number and any fraudulent entity they provide. We analyze this information and use Amazon EKS as the platform for deploying that application. We mainly deploy applications using Kubernetes deployments, and based on that, we deploy pods which contain the container that runs the application.

Amazon EKS helps us manage these deployments for threat analysis and synthetic identity because the controller part is managed by AWS. This addresses our concern about managing it ourselves, as we are managing a large environment where Amazon EKS ensures we can confidently manage our application rather than relying solely on the controller. We have implemented Karpenter, which manages the nodes and continuously monitors to see if any nodes or pods are underutilized or unable to load. It identifies the requirements from the pod side, automatically creates a node, and schedules the pod based on its resource needs. This automation allows us to respond quickly, especially during high load times when pods may get stuck or unable to upload images. The alerts help us react promptly, and another pod will be scheduled to fulfill the user's request within seconds.

The best feature Amazon EKS offers is automation, particularly with the automatic scheduling of pods on nodes. Karpenter, the new feature added recently that manages the node initialization, is something I really appreciate as it makes independent decisions based on the requirements, unlike older autoscaling configurations. Karpenter prioritizes cost-effectiveness by selecting the cheapest options for nodes, whether they are spot instances or on-demand. Additionally, whenever there is an issue, the pod can be automatically recreated using the defined replica set, providing a significant advantage of Kubernetes.

Karpenter helps keep costs down by consistently evaluating whether it should take on-demand instances or lower-cost alternatives. It constantly monitors for the lowest price model available in AWS. However, because the cheapest instance can be terminated with little notice, Karpenter quickly transitions to the next available on-demand instance. This proactive cost management is a key feature.

Amazon EKS has positively impacted my organization as Kubernetes offers orchestration of container-based applications, allowing us to rapidly deploy and fulfill user requests. During busy business days or promotional offers, we experience increased traffic, and Amazon EKS enables quick deployment of containers to meet this demand. If a pod is unresponsive, Amazon EKS can easily launch another pod to maintain service delivery. This adaptability not only enhances user service but also contributes to cost savings since we leverage Karpenter to manage nodes dynamically based on usage.

Since I joined this company ten months ago, we have reduced the number of failures significantly. Earlier, before using Karpenter, issues with pods hindered our efficiency and resulted in higher costs, as we did not have the option to minimize expenses effectively. Now, with Karpenter, costs have decreased and our efficiency has improved because we can swiftly address alerts and redeploy applications without delay. This transition has greatly improved our operational performance.

After adding Karpenter to our Amazon EKS setup, we have seen efficiency improvements of approximately thirty to forty percent, along with a reduction in our costs and a decrease in the number of issues our team encounters.

In my experience with Amazon EKS, I have not encountered aspects that require improvement, as AWS has invested intelligently in its development, especially with the addition of Karpenter. I do not have any particular improvement feedback for Amazon EKS or Kubernetes at this time.

I have been working in my current field for the last ten months. In terms of my total experience, I have been using Amazon EKS for the last three years, and in my current company, I have been using it for the last ten months.

Amazon EKS is stable in my experience.

Customer support for Amazon EKS is excellent, particularly at the enterprise level, as we can readily raise tickets and receive prompt responses. This interactive support is incredibly useful, allowing for quick resolutions and solutions through live sessions and screen sharing.

Positive

I have been using Amazon EKS since I started. Although I know about Docker Swarm, it poses issues for large environments like ours, which is why we opted for Amazon EKS.

We evaluated Docker Swarm before choosing Amazon EKS, as it is not well-suited for expanded environments and long-term deployments, making Amazon EKS the clear choice based on insights from my seniors.

I have experienced a return on investment with Amazon EKS. Since implementing Karpenter, costs have been reduced and operational efficiency has increased. We can deploy applications swiftly, and our monitoring tools such as DataDog alert us to any pod issues so we can act quickly. This responsiveness enables us to focus on critical issues that require our immediate attention.

I appreciate the overall pricing model of AWS, where you pay based on usage, which allows for a clear understanding of costs associated with services. The setup cost is reduced significantly since Amazon EKS simplifies the laborious process of arranging the controller plane, which typically requires substantial human resources and effort. Licensing is straightforward, making it easy to start using the service.

I would certainly recommend using Amazon EKS due to its managed services, which alleviate the complexities of controlling the Kubernetes cluster. The scalability features ensure issues with any pods are managed effectively by automatic relaunch processes, maintaining desired states. Karpenter's cost-efficient design is another highlight worth noting for anyone looking to balance container orchestration with spending.

Amazon EKS has proven to be an exceptional product, particularly as it gains popularity due to its scalability and rapid application deployment capabilities, benefiting organizations across various sectors. This review has been rated nine out of ten.

Public Cloud

Amazon Web Services (AWS)

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

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

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

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

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

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

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

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

I have been working with Amazon EKS for 4.7 years.

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

Negative

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

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

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

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

Public Cloud

Amazon Web Services (AWS)