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.
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 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.
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.
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.
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.
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.
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.
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.
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.
It was really positive. The customer support was nice, informative, and very helpful.
Positive
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.
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.
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.
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.
