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)

My use cases for Amazon EKS involve different types of workloads, mostly web-related and mobile application related, to orchestrate deployments and make application release easier, smoother, and faster.

What I appreciate best about Amazon EKS is that it's a great solution, especially for teams who search for flexibility and who are in active development of microservices architecture. It gives flexibility not only for DevOps but also for developers to control infrastructure through code, such as through the GitOps approach, which releases a lot of time and effort for system engineers and DevOps engineers to do their business and not provision servers by their own. Scalability and flexibility are the most useful cases there.

The benefits I have seen using Amazon EKS are substantial. Kubernetes is a complex structure, and if you have it self-maintained on your bare metal devices, it's first a pretty big chunk of the infrastructure. Plus, it's very complex and hard to maintain. Not all engineers have the knowledge to control a Kubernetes cluster. Having it as a service reduces release time dramatically. Amazon controls the versions, upgrades, security components, and related elements. It's easy to do system upgrades, even release another cluster in a matter of a few hours and move all workloads to the latest release of Amazon EKS if needed or for development environment testing. This would be much more difficult if you control your Kubernetes cluster manually as self-hosted.

What could be improved in Amazon EKS is the documentation. It's pretty dynamic, moving too fast, and sometimes the documentation doesn't reflect the migration between changes, especially if you use some non-native vendor enterprise components and CRDM modules. If you use only AWS UI, it's pretty hard to debug something in Amazon EKS. You need to be aware about kubectl or another toolset which allows you to dive deeper into the Kubernetes details. Not always do software developers have such expertise. If they could improve their debug capabilities, toolset for debugging, or maybe integrate it with their AI, such as Amazon Q, to support the developers, it could be valuable for developers.

I have been using Amazon EKS practically from the day they implemented this solution, which has been many years already.

I can easily scale up or down with Amazon EKS. Currently, Kubernetes and Amazon EKS itself have many different vendor solutions, native solutions or vendor solutions for scaling. It's easy to control and very cost-efficient.

The customer support from Amazon could be better. I find it problematic that customers who don't have a big budget are not able to use the customer support. If you don't have your support subscription, you're only able to use forums, which is challenging because sometimes software can have issues or the setup is pretty tricky and not reflected in the documentation.

Support quality depends on which engineers you're talking with. For bigger clients and companies, AWS dedicates an agent or manager as a point of contact for the specific team, and you can easily reach them and discuss initial key points. It's great. It doesn't always do what you would expect, but at least it's a very good and fast starting point to solve issues.

I would rate their support a seven out of ten.

Positive

I have previously used different solutions before Amazon EKS. For simpler solutions, we used Amazon ECS, which is a native Docker orchestrator. It's much simpler than Kubernetes but does the job well for a simple setup. It's a bit more difficult in the provisioning and control of components, but it works fine for static infrastructure. We used various solutions, from self-hosted Docker containers for ECS, Fargate, to Lambda functions. The choice depends on what you actually expect from your application and infrastructure.

Regarding the pricing of Amazon EKS, if we discuss EKS itself, it's relatively cheap at $75 for deployment for the control plane. However, for running a Kubernetes cluster, you need more resources even for the simplest deployment of any modules. It could be very expensive, but it's mostly about how the architecture is built and how the team controls the resources. It's not about Amazon EKS directly, but related.

I have used Amazon EKS integration with IAM. It's basically one of the core parts of the configurations not only for access to the cluster but also for the services themselves to provide them access to other Amazon resources.

My experience with the deployment in Amazon EKS is that it's easy and has many options for how you can control your deployment in Kubernetes from your native kubectl to the GitOps approach. I strongly support the GitOps approach to control everything and give developers access to infrastructure through GitOps and full code-controlled infrastructure. It's easy when you integrate everything and it works fine.

I would recommend Amazon EKS to others if they're sure that Kubernetes is what they would need. On a scale of 1-10, I rate Amazon EKS an 8.

Public Cloud

Amazon Web Services (AWS)

We use Amazon EKS for hosting our policy admin system, and it has its own benefits. The scalability aspect of it is what we considered Amazon EKS for. It is a managed service, so we don't need to take care of the underlying operating system and other things. It was one of the preferred services in AWS which we chose.

The benefits I have experienced with using the automated patching feature are key, because considering that this is a managed service, we want to be more focused on our application rather than doing all these upgrades, especially given the amount of upgrades at each of these microservices level applications. We don't want to worry about that, and there is always this blue and green setup which we can have where, if there are any issues, I should be able to switch over to my blue whenever there is a deployment. Those aspects have helped us.

What I appreciate best about Amazon EKS is the managed service part of it because we don't need to worry about the underlying operating systems or the upgrades we need to have. The flexibility at which we can spin up multiple pods in each of the Kubernetes service and the service availability aspect of it are the key points.

I have used the integration with IAM; we used IAM roles, focusing on security aspects. We had multiple IAM roles and policies defined so that it is quite secure.

A few improvements I can think of for Amazon EKS would be on the monitoring side; they have very good monitoring aspects of it, but it has its pros and cons. Having some access and visibility into their Amazon EKS services and setup would be good because there are instances where some of the pods crash, but we don't have detailed monitoring available since once the pod crashes, we can't get enough logs. If they can have a backdoor or backup capability, whenever a pod is not able to serve, to get all the metrics before killing it, that would help us investigate the reasoning behind it more thoroughly. I think that side of it is missing.

Regarding Amazon EKS pricing, they have corporate level discounts, but one key aspect is the pros and cons. One immediate deploy capability is that I can trigger a pipeline to get an Amazon EKS setup done and start using it, which is much more efficient in the short term. However, in the long run, the scenarios we've seen indicate that it requires integration with other services, and the network egress charges are a bit higher. The intent of starting with reduced costs using Amazon EKS doesn't hold as clearly when we consider it for the long run; we start with a low cost and then realize it doesn't justify that.

I have been using Amazon EKS for almost five years.

The support for AWS tools, such as integration, has significantly influenced our management. Considering that we are a big corporate with direct connects with the AWS solution architect and other people we work with, it's as simple as raising that support request and they will be here. I think we even had the highest level of support we can get from AWS with respect to this.

I think very highly of Amazon's support team; they are really good, especially considering that we have the highest level of support and their support management team is also involved in calls to give any kind of priority to our requests.

Positive

I would recommend Amazon EKS to other people, but it depends on the scenario. Kubernetes for sure, but I suggest going for Amazon EKS if yours is a smaller enterprise. If your load is too high and fluctuating, then it makes sense to try Amazon EKS, learn how Kubernetes works for your organization, and evaluate the cost-benefit analysis. If you are considering it for a longer run, I recommend conducting a cost analysis to see if moving to a local on-prem system could be more beneficial. It truly depends on the case scenario, so it's important to do the cost analysis as well. On a scale of one to ten, I rate Amazon EKS an eight.

Amazon Web Services (AWS)